-
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 elided lifetimes in associated constants (ELIDED_LIFETIMES_IN_ASSOCIATED_CONSTANT
)
#115011
Warn on elided lifetimes in associated constants (ELIDED_LIFETIMES_IN_ASSOCIATED_CONSTANT
)
#115011
Conversation
r? @TaKO8Ki (rustbot has picked a reviewer for you, use r? to override) |
c99b5dd
to
2456323
Compare
This comment has been minimized.
This comment has been minimized.
2456323
to
fad7d22
Compare
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.
r=me on the implementation
I wonder if we should notify t-lang somehow.
}; | ||
self.r.lint_buffer.buffer_lint_with_diagnostic( | ||
lint::builtin::ELIDED_LIFETIMES_IN_ASSOCIATED_CONSTANT, | ||
node_id, |
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.
Why not lifetime.id
here?
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.
Elided lifetimes are not present in the AST, so buffered lints on that node ID (lifetime.id
) will not get processed later, since that walks through the AST. This results in ICEs.
I consider this to be fully a compiler bug, so I'll cc @rust-lang/lang here, but I don't think there's a decision for them to make. If we wanted to, for example, stabilize a correct behavior here (e.g. lower elided to |
@bors r=cjgillot |
…oc-ct-lt, r=cjgillot Warn on elided lifetimes in associated constants (`ELIDED_LIFETIMES_IN_ASSOCIATED_CONSTANT`) Elided lifetimes in associated constants (in impls) erroneously resolve to fresh lifetime parameters on the impl since rust-lang#97313. This is not correct behavior (see rust-lang#38831). I originally opened rust-lang#114716 to fix this, but given the time that has passed, the crater results seem pretty bad: rust-lang#114716 (comment) This PR alternatively implements a lint against this behavior, and I'm hoping to bump this to deny in a few versions.
⌛ Testing commit fad7d22 with merge dcf0c926f6e689a7e93b263785ee0f95d65bd097... |
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
Some changes occurred in src/tools/rust-analyzer cc @rust-lang/rust-analyzer |
Sorry for the in-tree fix rust-analyzer, but can't land if RA fails CI 😅 |
Does that also fix #115068 (comment) ? |
⌛ Testing commit c5f9d42fac0c5a9b00a2391bce4750f27656b294 with merge 8b702df6d255c1f5992e312e5765517a6ceccc52... |
This comment has been minimized.
This comment has been minimized.
💔 Test failed - checks-actions |
c5f9d42
to
b1c609e
Compare
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.
RA change seems okay.
whoops forgot to reapprove @bors r=cjgillot |
…mpiler-errors Rollup of 6 pull requests Successful merges: - rust-lang#114959 (fix rust-lang#113702 emit a proper diagnostic message for unstable lints passed from CLI) - rust-lang#115011 (Warn on elided lifetimes in associated constants (`ELIDED_LIFETIMES_IN_ASSOCIATED_CONSTANT`)) - rust-lang#115077 (Do not emit invalid suggestion in E0191 when spans overlap) - rust-lang#115087 (Add disclaimer on size assertion macro) - rust-lang#115090 (Always use `os-release` rather than `/lib` to detect `NixOS` (bootstrap)) - rust-lang#115101 (triagebot: add dependency licensing pings) r? `@ghost` `@rustbot` modify labels: rollup
Changes were required due to: - rust-lang/rust#115011 - rust-lang/rust#114993
Changes were required due to: - rust-lang/rust#115011 - rust-lang/rust#114993
…rough, r=cjgillot Fall through when resolving elided assoc const lifetimes `@QuineDot` makes a good point in rust-lang#115010 (comment) that we probably should not accept *more* code due to rust-lang#115011 even though that code will eventually become a forbid-warning in a few versions (rust-lang#115010 (comment)). Fall through when walking thru the `AnonymousWarnToStatic` (renamed to `AnonymousWarn`) rib so that we can resolve as a fresh lifetime like we did before.
…rough, r=cjgillot Fall through when resolving elided assoc const lifetimes ``@QuineDot`` makes a good point in rust-lang#115010 (comment) that we probably should not accept *more* code due to rust-lang#115011 even though that code will eventually become a forbid-warning in a few versions (rust-lang#115010 (comment)). Fall through when walking thru the `AnonymousWarnToStatic` (renamed to `AnonymousWarn`) rib so that we can resolve as a fresh lifetime like we did before.
…ugh, r=cjgillot Fall through when resolving elided assoc const lifetimes `@QuineDot` makes a good point in rust-lang#115010 (comment) that we probably should not accept *more* code due to rust-lang#115011 even though that code will eventually become a forbid-warning in a few versions (rust-lang#115010 (comment)). Fall through when walking thru the `AnonymousWarnToStatic` (renamed to `AnonymousWarn`) rib so that we can resolve as a fresh lifetime like we did before.
…oc-ct-lt, r=cjgillot Warn on elided lifetimes in associated constants (`ELIDED_LIFETIMES_IN_ASSOCIATED_CONSTANT`) Elided lifetimes in associated constants (in impls) erroneously resolve to fresh lifetime parameters on the impl since rust-lang#97313. This is not correct behavior (see rust-lang#38831). I originally opened rust-lang#114716 to fix this, but given the time that has passed, the crater results seem pretty bad: rust-lang#114716 (comment) This PR alternatively implements a lint against this behavior, and I'm hoping to bump this to deny in a few versions.
Warn, | ||
"elided lifetimes cannot be used in associated constants in impls", | ||
@future_incompatible = FutureIncompatibleInfo { | ||
reason: FutureIncompatibilityReason::FutureReleaseError, |
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.
FWIW this FutureIncompatibilityReason will make the warning only show up in locally built crates, but not in cargo's future breakage report that also shows warnings from dependencies. Just making sure that this is a deliberate choice and not an accident. :)
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.
Not deliberate, but isn't it conventional to bump it later? Possibly at the same time that this lint gets bumped to Deny? Not sure if there's a definite process for how to gradually raise FCW severity 🫠
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.
I don't think we have a standard process. :/
Elided lifetimes in associated constants (in impls) erroneously resolve to fresh lifetime parameters on the impl since #97313. This is not correct behavior (see #38831).
I originally opened #114716 to fix this, but given the time that has passed, the crater results seem pretty bad: #114716 (comment)
This PR alternatively implements a lint against this behavior, and I'm hoping to bump this to deny in a few versions.