-
-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding #[must_use]
on an item
#268
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good! If you'd like, we can merge it right now. If you'd prefer to merge multiple must_use
lints at the same time, that's fine too — I don't have a strong preference either way.
I think we'll also need
Yes, of course. Please feel free to add it. The schema also lacks constants and statics, which would be great to have as well — we don't have a way to represent their type, so we can just skip adding it to the schema for now and add it later. |
Co-authored-by: Predrag Gruevski <2348618+obi1kenobi@users.noreply.github.com>
I would definitely like to add the struct, function and trait lints before merging, as well as the method lint. After that we can either merge it and specify the #159 issue to the |
First of all, sorry for making this large push - I was not expecting it myself to end up this way... After pushing the What's changed?
What's next?From my point of view, the best solution would be to merge this PR with currently added lints, add the missing If possible, it would be great to merge the 2 test crates without lints ( These are just my ideas though, and I will fully agree with whatever works best in your opinion! |
I'm excited to get all these new lints merged! Unfortunately, this PR is way too large to be realistically reviewable as-is. There's quite a bit of tricky stuff going on (especially in the method lints), and I really want to avoid having to re-review 1600+ lines of code through multiple rounds of comments. Please split it up into multiple PRs, at least 3 of them if not more:
This sounds fine.
I believe these have a visibility modifier called
I think it's not worth implementing this lint for this case, since this is already by itself semver-minor even withour It would be great to have a test case for this case, to make sure we aren't reporting a lint here. |
Also by all means please implement the missing schema part you ran into! |
I will create a separate PR for each one of the lints (smaller is a lot better and easier, I regret not doing it from the start). I also was not aware what the
Knowing how the
Agreed, the lint was not implemented yet anyways.
Sure, the test crate stay under the name |
I currently don't understand the distinction between these two lints. What are the arguments for and against merging them? Is there a risk of getting duplicate lints if they stay separate? If you'd like, just use your best judgment to move forward and we can discuss more on the smaller PR.
It's hard for me to say without digging really deep into this PR, which wouldn't be an efficient use of time: you've shown you have good judgment, so I trust you to make a good decision as part of splitting up the PR and if needed, we can chat about it more on the new, smaller PRs. |
This PR was successfully split into smaller PRs and is now closed. |
#159 Adding
#[must_use]
on an itemAccording to Rust Reference about
#[must_use]
attribute, the following lints have to be added:Having already done the enum lint I thought it would be a good idea to ask for a review before adding the rest of the lints, especially because they would be very similar to one another (besides tests, only single-word changes in generated messages).
Also a question @obi1kenobi - if I'm not mistaken, we currently do not have a Union item in the adapter. If there are plans to eventually include it in the schema, maybe this is a good moment to do so?