Skip to content
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

Tracking issue for RFC 2115: In-band lifetime bindings #44524

Closed
3 of 10 tasks
aturon opened this issue Sep 12, 2017 · 152 comments · Fixed by #93845
Closed
3 of 10 tasks

Tracking issue for RFC 2115: In-band lifetime bindings #44524

aturon opened this issue Sep 12, 2017 · 152 comments · Fixed by #93845
Labels
A-lifetimes Area: Lifetimes / regions B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. disposition-close This PR / issue is in PFCP or FCP with a disposition to close it. E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. finished-final-comment-period The final comment period is finished for this PR / Issue. S-tracking-design-concerns Status: There are blocking ❌ design concerns. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@aturon
Copy link
Member

aturon commented Sep 12, 2017

Update for 2022: With the FCP close finished, this is no longer on a stabilization path, and will likely be removed from nightly. The issue will remain open so long as it's referenced by an implemented feature in the compiler, however.


This is a tracking issue for the RFC "In-band lifetime bindings" (rust-lang/rfcs#2115).

Steps:

Unresolved questions:

  • What conventions should we use for lifetime names, and should they be enforced via lint?
  • Can we find an unequivocally-better syntax than '_ for elided lifetimes?
    • These are now stable, so we didn't

Known bugs (possibly incomplete list):

@aturon aturon added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-lang Relevant to the language team, which will review and decide on the PR/issue. labels Sep 12, 2017
@glaebhoerl
Copy link
Contributor

@aturon Could we word the unresolved question as something like "what is the appropriate convention, if any" rather than "is this particular convention worthwhile"? Thanks!

@vitiral
Copy link
Contributor

vitiral commented Sep 12, 2017

also, that wasn't the only suggested alternative. There is also completely explicit lifetimes using 'self::lifetime_name

@durka
Copy link
Contributor

durka commented Sep 12, 2017

$ rg -F "impl<'a>" /rust/src | wc -l
     730

This supposedly ergonomic change is going to require updating a lot of code, including all of our docs and examples. I guess you could just do s/'a/'aa but that seems to miss the point. Could we make some kind of interactive rustfix tool to let you choose new lifetime names and have them automatically updated?

@aturon
Copy link
Member Author

aturon commented Sep 12, 2017

@glaebhoerl Done, thanks!

@nikomatsakis
Copy link
Contributor

I expanded the unresolved question a bit.

@nikomatsakis nikomatsakis added E-needs-mentor T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Sep 15, 2017
@nikomatsakis nikomatsakis added this to the impl period milestone Sep 15, 2017
@aturon aturon removed this from the impl period milestone Sep 15, 2017
@TimNN TimNN added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Sep 17, 2017
@nikomatsakis
Copy link
Contributor

nikomatsakis commented Sep 18, 2017

Mentoring instructions

I'm not sure 100% the best way to implement this yet, but let me start by giving some pointers. Perhaps @eddyb can elaborate, as he is the last one to touch the relevant code in a serious way, as far as I know.

First thing is a kind of list of what the tasks are in the RFC. This is roughly the order in which I think we should approach them. It may even be worth breaking this out into separate issues.

XXX task list moved into main header

I don't have time for detailed mentoring notes, but here are a few things to start reading into. At present, region resolution etc kind of works like this:

  • During HIR lowering, we insert placeholders for elided lifetimes.
  • After HIR lowering, we run the code in resolve_lifetime.rs.
  • This creates the NamedRegionMap that, for each hir::Lifetime, contains a Region struct indicating what region is being named.
    • This struct is a bit complicated. =)

@eddyb
Copy link
Member

eddyb commented Sep 18, 2017

To support '_ we have to do very little:

@nikomatsakis nikomatsakis added E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. and removed E-needs-mentor labels Sep 21, 2017
bors added a commit that referenced this issue Sep 22, 2017
@nikomatsakis nikomatsakis removed the E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. label Sep 25, 2017
bors added a commit that referenced this issue Nov 23, 2017
Implement in-band lifetime bindings

TODO (perhaps in a future PR): Should we ban explicit instantiation of generics with in-band lifetimes, or is it uncontroversial to just append them to the end of the lifetimes list?

Fixes #46042, cc #44524.

r? @nikomatsakis
@SimonSapin
Copy link
Contributor

Lint against single-letter lifetimes not confined to functions

Sorry that I come “after the battle” (this RFC was accepted during the pre-impl-period rush), but as @durka pointed out applying this lint to existing code bases will likely generate a lot of busy work for questionable benefits. I looked for the rationale for this lint but couldn’t find it. https://rust-lang.github.io/rfcs/2115-argument-lifetimes.html#lifetimes-in-impl-headers mentions a “convention”, but doesn’t say why enforcing it is important enough to warn by default. We don’t have such a lint for local variable names or field names, for example.

I assume that proposed lints are intended to warn by default. If they’re silent by default I have no concern.

@rpjohnst
Copy link
Contributor

The idea is that there will no longer be <'a> sections in functions, so it will be harder to tell apart lifetime names from impl scope and those from function scope. This makes it tricky to know whether a name used in a function is intended to refer to an impl-scope lifetime, or to define a new one (and should thus be renamed).

@SimonSapin
Copy link
Contributor

@rpjohnst Sorry, I have a hard time figuring out if your comment is arguing for or against something, and whether that thing is the lint I mentioned or some other change proposed by this tracking issue.

@rpjohnst
Copy link
Contributor

@SimonSapin It's just trying to describe the reasoning behind the lint's existence, not necessarily argue for or against it.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Dec 8, 2021
…rochenkov

Remove `in_band_lifetimes` from `rustc_mir_transform`

Like rust-lang#91580, this was inspired by the conversation in rust-lang#44524 about possibly removing the feature from the compiler.  This crate is a heavy `'tcx` user, so is a nice case study.

r? ``@petrochenkov``

Three interesting ones:

This one had the `'tcx` declared on the function, despite the trait taking a `'tcx`:
```diff
-impl Visitor<'_> for UsedLocals {
+impl<'tcx> Visitor<'tcx> for UsedLocals {
     fn visit_statement(&mut self, statement: &Statement<'tcx>, location: Location) {
```

This one use in-band for one, and underscore for the other:
```diff
-pub fn remove_dead_blocks(tcx: TyCtxt<'tcx>, body: &mut Body<'_>) {
+pub fn remove_dead_blocks<'tcx>(tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) {
```

A spurious name, since there's no single-use-lifetime warning:
```diff
-pub fn run_passes(tcx: TyCtxt<'tcx>, body: &'mir mut Body<'tcx>, passes: &[&dyn MirPass<'tcx>]) {
+pub fn run_passes<'tcx>(tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>, passes: &[&dyn MirPass<'tcx>]) {
```
@nikomatsakis
Copy link
Contributor

@rfcbot fcp reviewed

I agree with what @scottmcm wrote. I am definitely still interested in us spending time to address some of the ergonomic pain around using lifetimes, but I'd want to step back and do an initiative, and in particular to spend some time identifying precisely which problems are most pressing now.

@scottmcm
Copy link
Member

@davidtwco @estebank @nagisa Friendly one-week ping for the FCP close here. It only needs one more ✅!

@davidtwco
Copy link
Member

@davidtwco @estebank @nagisa Friendly one-week ping for the FCP close here. It only needs one more ✅!

@rfcbot rfcbot added the final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. label Dec 14, 2021
@rfcbot
Copy link

rfcbot commented Dec 14, 2021

🔔 This is now entering its final comment period, as per the review above. 🔔

@rfcbot rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Dec 14, 2021
@matklad
Copy link
Member

matklad commented Dec 17, 2021

One no-brainer thing we can do to help here is to add an in-editor fix to create a declaration for “in-band” lifetimes

rust-lang/rust-analyzer#11039

@rfcbot rfcbot added finished-final-comment-period The final comment period is finished for this PR / Issue. and removed final-comment-period In the final comment period and will be merged soon unless new substantive objections are raised. labels Dec 24, 2021
@rfcbot
Copy link

rfcbot commented Dec 24, 2021

The final comment period, with a disposition to close, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

@rfcbot rfcbot added the to-announce Announce this issue on triage meeting label Dec 24, 2021
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Dec 30, 2021
@joshtriplett joshtriplett added the S-tracking-design-concerns Status: There are blocking ❌ design concerns. label Feb 9, 2022
@scottmcm scottmcm added E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. E-help-wanted Call for participation: Help is requested to fix this issue. labels Feb 9, 2022
@scottmcm
Copy link
Member

scottmcm commented Feb 9, 2022

With the FCP completed here, this is currently open because the feature still exists in the compiler, with the tracking issue number referencing this item:

(active, in_band_lifetimes, "1.23.0", Some(44524), None),

We're unsure how difficult it will be to remove the code about this from the compiler, but if anyone is interesting in picking up something, grepping for the feature should give a bunch of places to start:

https://github.com/rust-lang/rust/search?q=in_band_lifetimes+path%3Acompiler

@scottmcm scottmcm removed the E-help-wanted Call for participation: Help is requested to fix this issue. label Feb 10, 2022
Manishearth added a commit to Manishearth/rust that referenced this issue Feb 24, 2022
…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 added a commit to Dylan-DPC/rust that referenced this issue Feb 24, 2022
…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 added a commit to Dylan-DPC/rust that referenced this issue Feb 24, 2022
…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
@bors bors closed this as completed in ec4fc72 Feb 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-lifetimes Area: Lifetimes / regions B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. disposition-close This PR / issue is in PFCP or FCP with a disposition to close it. E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. finished-final-comment-period The final comment period is finished for this PR / Issue. S-tracking-design-concerns Status: There are blocking ❌ design concerns. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.