-
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
Remove in band lifetimes #93845
Remove in band lifetimes #93845
Conversation
Some changes occurred in diagnostic error codes |
@@ -684,7 +680,7 @@ impl<'a, 'hir> LoweringContext<'a, 'hir> { | |||
// that collisions are ok here and this shouldn't | |||
// really show up for end-user. | |||
let (str_name, kind) = match hir_name { | |||
ParamName::Plain(ident) => (ident.name, hir::LifetimeParamKind::InBand), | |||
ParamName::Plain(ident) => (ident.name, hir::LifetimeParamKind::Explicit), |
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 is the only suspicious change.
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.
Async blocks, for example, declare named elided lifetimes (idk if that's the only one, perhaps closures?). We should give them a category here -- not sure if it's correct to use LifetimeParamKind::Explicit
though. Maybe I can add a new LifetimeParamKind
like Implicit
.
It all funnels into hir::LifetimeDefOrigin::ExplicitOrElided
though, so I don't think the distinction matters?
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 case should only happen when synthetizing lifetimes for an async fn return impl Future
type. There should not be a difference, but we got bit before.
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.
Once LifetimeDefOrigin
is removed, LifetimeParamKind
is only used in lifetime resolution diagnostics and rustdoc to filter elided lifetimes. Therefore LifetimeParamKind::Explicit
is fine.
This comment has been minimized.
This comment has been minimized.
Thank you CI -- I'll add those error codes back then! @rustbot author |
@@ -141,13 +141,9 @@ struct LoweringContext<'a, 'hir: 'a> { | |||
/// indicate whether or not we're in a place where new lifetimes will result | |||
/// in in-band lifetime definitions, such a function or an impl header, | |||
/// including implicit lifetimes from `impl_header_lifetime_elision`. | |||
is_collecting_in_band_lifetimes: bool, | |||
is_collecting_anonymous_lifetimes: bool, |
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 renamed this to anonymous
, since this handles both elided and in-band lifetimes, but we now only have the former. Open to calling this something like is_collecting_elided_lifetimes
tho!
b6dc969
to
7b9d78a
Compare
I think this is ready for.. at least an initial review @rustbot ready |
This comment has been minimized.
This comment has been minimized.
52cdc39
to
c068a70
Compare
Thanks for making the PR so quickly! ❤️ I'm not a compiler reviewer, though, so since you mention there are few nuanced bits here, it's probably better than someone who knows it better takes a look. r? rust-lang/compiler I could probably review some pieces, if you felt like splitting it up. (It seems like there are some easy bits, like updating tests that aren't about in-band to stop using it. Or maybe removing the special "do you want to try in-band?" hint would be a pure removal.) But since this is almost entirely red, it's not clear to me that it would be worth the effort of splitting. Hopefully the compiler reviewer will just be able to skim it and go "yup, seems fine". |
This comment has been minimized.
This comment has been minimized.
e4c51b8
to
9e53b97
Compare
This comment has been minimized.
This comment has been minimized.
Take a look at some other error explanations not emitted by the compiler anymore to see how they handle the code examples (spoiler alert: use |
9e53b97
to
9a99cb3
Compare
📌 Commit 43dbd83 has been approved by |
…r=cjgillot Remove in band lifetimes As discussed in t-lang backlog bonanza, the `in_band_lifetimes` FCP closed in favor for the feature not being stabilized. This PR removes `#![feature(in_band_lifetimes)]` in its entirety. Let me know if this PR is too hasty, and if we should instead do something intermediate for deprecate the feature first. r? `@scottmcm` (or feel free to reassign, just saw your last comment on rust-lang#44524) Closes rust-lang#44524
…r=cjgillot Remove in band lifetimes As discussed in t-lang backlog bonanza, the `in_band_lifetimes` FCP closed in favor for the feature not being stabilized. This PR removes `#![feature(in_band_lifetimes)]` in its entirety. Let me know if this PR is too hasty, and if we should instead do something intermediate for deprecate the feature first. r? ``@scottmcm`` (or feel free to reassign, just saw your last comment on rust-lang#44524) Closes rust-lang#44524
…r=cjgillot Remove in band lifetimes As discussed in t-lang backlog bonanza, the `in_band_lifetimes` FCP closed in favor for the feature not being stabilized. This PR removes `#![feature(in_band_lifetimes)]` in its entirety. Let me know if this PR is too hasty, and if we should instead do something intermediate for deprecate the feature first. r? ```@scottmcm``` (or feel free to reassign, just saw your last comment on rust-lang#44524) Closes rust-lang#44524
@Dylan-DPC wrong PR referenced? |
ye fixed now :P |
I'll re-bless when I get back to my computer. |
43dbd83
to
9386ea9
Compare
Had to bless tests with when you have the free time, @cjgillot can you r+ again? thank you! |
@bors r=cjgillot |
📌 Commit 9386ea9 has been approved by |
…askrgr Rollup of 7 pull requests Successful merges: - rust-lang#93845 (Remove in band lifetimes) - rust-lang#94155 (Extend toggle GUI test a bit) - rust-lang#94252 (don't special case `DefKind::Ctor` in encoding) - rust-lang#94305 (Remove an unnecessary restriction in `dest_prop`) - rust-lang#94343 (Miri fn ptr check: don't use conservative null check) - rust-lang#94344 (diagnostic: suggest parens when users want logical ops, but get closures) - rust-lang#94352 (Fix SGX docs build) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
As discussed in t-lang backlog bonanza, the
in_band_lifetimes
FCP closed in favor for the feature not being stabilized. This PR removes#![feature(in_band_lifetimes)]
in its entirety.Let me know if this PR is too hasty, and if we should instead do something intermediate for deprecate the feature first.
r? @scottmcm (or feel free to reassign, just saw your last comment on #44524)
Closes #44524