Split elided_lifetime_in_paths into tied and untied

[shepmaster]

Before merging

• Discuss "tied" / "untied" terminology. Blocking this PR.
• Discuss "deprecated" terminology. Non-blocking.
• Discuss the async fn hard error case. Non-blocking.

Description

Types that contain a reference can be confusing when lifetime elision occurs:

// Confusing
fn foo(_: &u8) -> Bar { todo!() }

// Less confusing
fn foo(_: &u8) -> Bar<'_> { todo!() }

However, the previous lint did not distinguish when these types were not "tying" lifetimes across the function inputs / outputs:

// Maybe a little confusing
fn foo(_: Bar) {}

// More explicit but noisier with less obvious value
fn foo(_: Bar<'_>) {}

We now report different lints for each case, hopefully paving the way to marking the first case (when lifetimes are tied together) as warn-by-default (#91639).

Additionally, when multiple errors occur in the same function during the tied case, they are coalesced into one error. There is also some help text pointing out where the lifetime source is.

To discuss

"Tied" terminology

The lints are called elided_lifetimes_in_paths_tied and elided_lifetimes_in_paths_untied, under a lint group of elided_lifetimes_in_paths. The usage of "tied" and "untied" introduces new terminology for a concept that is not new.

We had a discussion about other phrasing, but no super strong alternative arose. "tied" is not the most beautiful choice, but it's serviceable.

Beyond "tied", a good argument has been made that the current lint name is factually incorrect (tl;dr: both Foo and Foo<'_> perform lifetime elision; Foo has a hidden lifetime while Foo<'_> has explicit syntax). A follow up PR could rename these lints to be more accurate.

Suggested resolution

Do nothing today. This phrasing is good enough to merge and we can always rename and leave aliases.

Alternate resolutions

Decorate the bikeshed for a few days/weeks/months/editions.

"Deprecated" terminology

The current wording of the diagnostic is (emphasis mine)

hidden lifetime parameters in types are deprecated

This suggests that at some point we want to completely stop supporting this and make it into a hard error that cannot be disabled. This seems like a strong prescription, given the turbulence this lint has had throughout its life.

Suggested resolution

Do nothing today. Assume we really do want to deprecate this capability. We may want to evaluate which cases we really want to deprecate (e.g. fn(_: ContainsLifetime) is generally considered harmless) and tweak the error message to better distinguish which patterns are on a path to being removed.

Alternate resolutions

Decide we don't want to deprecate it and pick a softer wording.

Existing hard errors

async and non-async functions are treated differently today:

struct ContainsLifetime<'a>(&'a ());

// This is not even a warning
fn demo_sync(x: ContainsLifetime) -> ContainsLifetime { x }

// This is an error
async fn demo_async(x: ContainsLifetime) -> ContainsLifetime { x }

It seems like the two cases should be the same.

Suggested resolution

Do nothing today. At some point, change elided_lifetimes_in_paths_tied to warn-by-default, then error-by-default (likely over an edition), then become a hard error (as suggested in the "deprecation" discussion). At that point, the two cases should be identical.

Alternate resolutions

We could dial back the async fn hard error to become error-by-default or warn-by-default, matching whatever desired end state we want.

[rustbot]

r? @pnkfelix

rustbot has assigned @pnkfelix.
They will have a look at your PR within the next two weeks and either review your PR or
reassign to another reviewer.

Use r? to explicitly pick a reviewer

[shepmaster]

As I've now tried to add this test twice and to help prevent trying to add it again... this fails because elision can't take place:

fn top_level_nested_to_top_level_nested(v: &ContainsLifetime) -> &ContainsLifetime { v }

error[E0106]: missing lifetime specifiers
 --> src/lib.rs:3:66
  |
3 | fn top_level_nested_to_top_level_nested(v: &ContainsLifetime) -> &ContainsLifetime {
  |                                            -----------------     ^^^^^^^^^^^^^^^^^ expected named lifetime parameter
  |                                                                  |
  |                                                                  expected named lifetime parameter
  |

[pnkfelix]

This generally looks fine. I had a few questions about what we expect to happen in a corner case.

r=me once those questions are addressed in some way (update: well, maybe the r=me is premature given the list of questions that @shepmaster included in the PR description. But I don't think the PR is waiting on review at this point.)

@rustbot label: +S-waiting-on-author -S-waiting-on-review

[pnkfelix]

Oh, I suppose there is still an open question about the use of the "tied"/"untied" terminology, which I admit threw me for a loop at first. I'm not sure which group is the best to handle resolving that question, though. And I'm also not entirely sure that resolving that question should block landing this work.

Is resolving a question like that a matter for WG-diagnostics, or for T-lang?

[shepmaster]

Is resolving a question like that a matter for WG-diagnostics, or for T-lang?

That's a great question that I don't have an answer for. I posed it in the Zulip thread hoping there was some existing terminology. Unfortunately, no one seemed aware of one. "Tied" made some intuitive sense for the small handful of people I asked one-on-one.

It feels like this is something that we must have talked about before and potentially even documented somewhere, but 🤷

[danielhenrymantilla]

If we are to nitpick about this, an elided lifetime refers to both Foo and Foo<'_> (as per the official lifetime elision rules), with the former being implicitly elided, and the latter, explicitly (very unfortunate that the original lint picked that name 😔). Hidden is a more concise word which we could reach for, now.

For the purpose of the lint, I'd also move the adjective around, since elided_lifetimes_in_paths_tied does not roll off the tongue too much.

Finally, on the most controversial/debatable aspect of the exact word being picked here (e.g., "tied"), my own subjective two cents on the topic, would be to not overthink it, and use meaningful: meaningful_lifetimes_hidden_in_paths. The other one could use free: free_lifetimes_hidden_in_paths.

[shepmaster]

I'm sympathetic to this feedback, but some points arise when trying to implement some of the suggestions:

• Calling the lints a_commonpart and b_commonpart means that they won't appear near each other in alphabetical lists (which are numerous).
• There's another lint (ELIDED_LIFETIMES_IN_ASSOCIATED_CONSTANT) that should probably be updated.
• I'm torn between "hidden lifetimes" and "lifetimes hidden".
• There's a lot of other "elided" lifetimes in rustc_resolve's late.rs. I don't know which style they mean. Having both terms with mixed meanings may make things worse until someone cleans up all the code.

[danielhenrymantilla]

Yeah, fair enough

[shepmaster]

Alright, I've pushed a commit on top that changes to lifetimes_hidden_in_paths / tied_lifetimes_hidden_in_paths / untied_lifetimes_hidden_in_paths. This should allow us to see how we feel about it with some concrete code to look at.

TODO If we want to continue on this route, I did forget to rename the test files themselves.

[shepmaster]

...and I removed that commit from this PR, although I still have it locally. It looks like this PR will have enough trouble getting feedback, so let's go smaller.

[estebank]

When it comes to nomenclature of the lints, I have a bias towards keeping the name of the group as a substring of the individual lints, and I agree with some of daniel's observations, so my personal preference would be to name these lints ELIDED_LIFETIMES_IN_PATHS_EXPLICIT (not 100% sure on this one) and ELIDED_LIFETIMES_IN_PATHS_HIDDEN.

[danielhenrymantilla]

Thanks for pushing this forward! ❤️

[bors]

☔ The latest upstream changes (presumably #121780) made this pull request unmergeable. Please resolve the merge conflicts.

[RalfJung]

A follow up PR could rename these lints to be more accurate.

I don't think we want to rename and then immediately rename again.

[RalfJung]

It would be good to get a summary of what exactly those lints are covering each. I'm actually not sure, I thought "tied" was about lifetimes that appear in the return type (which is why I think the lint name should involve the term return or output or so), but on Zulip @shepmaster seemed to disagree with that.

[davidtwco]

I don't have an opinion on these lints or their naming, but the implementation LGTM.

[tmandry]

My suggestion would be elided_output_lifetimes_in_paths for the "tied" variant and elided_input_lifetimes_in_paths for "untied". It's true that a lifetime can be used in both input and output positions, but if it is used anywhere in an output position we can call it an "output lifetime" while also linting on its elision in the input position. Whereas "input" for elided_input_lifetimes_in_paths would be short for "input-only".

[nikomatsakis]

Some thoughts on naming:

• I like a suggestion that @pnkfelix made to distinguish elided lifetimes (those that are not syntactically visible at all) from anonymous lifetimes (either &T or '_).
• I think @scottmcm's suggestions like "multi-use lifetime" are decent, but I do like @tmandry's suggestion of using the adjective "output" -- i.e., elided_output lifetime -- to refer to a "lifetime that appears in the output" (even if it is actually elided in one of the inputs).

Side note that I expect that we may someday add "output elision" in contexts outside of function return values (e.g., associated type values or struct field types), but the name "output" seems generic enough to cover that.

[tmandry]

hidden lifetime parameters in types are deprecated

I also think we should remove this wording at least until we upgrade some lint to warn-by-default.

[traviscross]

• I like a suggestion that @pnkfelix made to distinguish elided lifetimes (those that are not syntactically visible at all) from anonymous lifetimes (either &T or '_).

Perhaps we could lean into the word "hidden". When I look at...

struct S<'a>(&'a ());
fn f(x: &()) -> S { S(x) }

...I think of that lifetime on S as being "hidden". Conversely, on references, lifetimes are "elided".

Then we could say that both elided and hidden uses expand implicitly into anonymous lifetime parameters, which can be written explicitly as '_.

[RalfJung]

I like "hidden", since we already use "lifetime elision" for all the existing cases, including &T -- so IMO we'd be redefining an existing term if we stopped calling &T an "elided" lifetime. Also, "hidden" conveys a slight judgement, making it more clear why this is something we want to lint against.

[shepmaster]

Trying to synthesize previous discussion, I've picked two names and done the renaming in a separate commit not in this PR:

• The lint group is hidden-lifetimes-in-paths
• The lint that people feel is most valuable is now hidden-lifetimes-in-output-paths
• The lint for the remaining cases is now hidden-lifetimes-in-input-paths

If people feel strongly positive about the renaming, I can also rebase this PR to perform the renaming first as one commit and split in a second commit. That way there's not a point where the main branch would ever experience the interim "tied" names.

[traviscross]

Calling these hidden seems right to me. Let's check for consensus on this variation:

• The lint group is hidden-lifetimes-in-paths.
• Case 1: The fn(W) -> W case is hidden-lifetimes-in-output-paths.
• Case 2: The fn(W) case is hidden-lifetimes-in-input-paths-only.
• Case 3: The f::<W> / <W>::f() case is hidden-lifetimes-in-type-paths.

This adds "only" to the second case, as otherwise it would seem logically odd for that one to not fire for:

struct W<'a>(&'a ());
fn f(x: W) -> W { x }

The third case covers:

struct W<'a>(&'a ());
fn f<T>() {}
fn main() {
    _ = f::<W>();
}

And this:

trait Tr { fn m() {}}
impl<T> Tr for T {}
struct W<'a>(&'a ());
fn main() {
    _ = <W as Tr>::m();
}

And this:

struct W<'a>(&'a ());
static S: W  = W(&());

@rfcbot fcp merge

[rfcbot]

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

Concerns:

• other-instead-of-input resolved by Split elided_lifetime_in_paths into tied and untied #120808 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.