-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Warn on unused lifetime parameters #41960
Comments
Yikes, no warnings at all. fn main() {
trait T {}
impl<'a> T for u8 {}
} |
Remove unused lifetimes. This was a typo that made it onto master. Noted by @dtolnay in rust-lang#42127. Also note rust-lang#41960 which suggests warning these.
Triage: no change. |
Note that this is currently intentional behaviour: rust/src/librustc_typeck/impl_wf_check.rs Line 115 in e575773
rust/src/librustc_typeck/impl_wf_check.rs Lines 139 to 156 in e575773
|
@varkor they should be accepted, just linted. |
I think this still needs a warn-by-default lint, because I just spotted this in liballoc: rust/src/liballoc/collections/vec_deque.rs Lines 2227 to 2236 in 9a3392e
Edit: found another one: Lines 322 to 330 in 9a3392e
|
Use more impl header lifetime elision Inspired by seeing explicit lifetimes on these two: - https://doc.rust-lang.org/nightly/std/slice/struct.Iter.html#impl-FusedIterator - https://doc.rust-lang.org/nightly/std/primitive.u32.html#impl-Not And a follow-up to rust-lang#54687, that started using IHLE in libcore. Most of the changes in here fall into two big categories: - Removing lifetimes from common traits that can essentially never user a lifetime from an input (particularly `Drop`, `Debug`, and `Clone`) - Forwarding impls that are only possible because the lifetime doesn't matter (like `impl<R: Read + ?Sized> Read for &mut R`) I omitted things that seemed like they could be more controversial, like the handful of iterators that have a `Item: 'static` despite the iterator having a lifetime or the `PartialEq` implementations [where the flipped one cannot elide the lifetime](https://internals.rust-lang.org/t/impl-type-parameter-aliases/9403/2?u=scottmcm). I also removed two lifetimes that turned out to be completely unused; see rust-lang#41960 (comment)
Use more impl header lifetime elision Inspired by seeing explicit lifetimes on these two: - https://doc.rust-lang.org/nightly/std/slice/struct.Iter.html#impl-FusedIterator - https://doc.rust-lang.org/nightly/std/primitive.u32.html#impl-Not And a follow-up to rust-lang/rust#54687, that started using IHLE in libcore. Most of the changes in here fall into two big categories: - Removing lifetimes from common traits that can essentially never user a lifetime from an input (particularly `Drop`, `Debug`, and `Clone`) - Forwarding impls that are only possible because the lifetime doesn't matter (like `impl<R: Read + ?Sized> Read for &mut R`) I omitted things that seemed like they could be more controversial, like the handful of iterators that have a `Item: 'static` despite the iterator having a lifetime or the `PartialEq` implementations [where the flipped one cannot elide the lifetime](https://internals.rust-lang.org/t/impl-type-parameter-aliases/9403/2?u=scottmcm). I also removed two lifetimes that turned out to be completely unused; see rust-lang/rust#41960 (comment)
Found something like this in my codebase today. No warning from rustc or clippy. |
Any plans to add a warn-by-default lint? |
We have an |
@Mark-Simulacrum it is not warn by default and I think it probably should be (gated may be on ecosystem prevalence). |
Hm, yeah, that makes sense. Reopening. I personally think we can probably "just" land this as a PR with FCP T-lang. |
#64493 should be considered blocking for making this warn-by-default. |
#86615 should also be considered blocking. |
With #86615 now fixed on the latest nightly, is there anything blocking this? |
I was assuming there aren't any blockers so I started looking into it a little bit, but I'm new to the codebase so it might take me a while especially given the holidays. If you'd like to take it over, be my guest! There's no shortage of open issues, and I'm sure I can both find something else to work on and also learn from reading the PR that fixes this issue 😃 |
Closing this in favor of #94038, which is tracking the enabling of this by default -- I opted to file a new issue so that we have a cleaner history given its tracking status. |
Somehow this made it into master without being warned:
This should definitely trigger a warning.
The text was updated successfully, but these errors were encountered: