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.

[shepmaster]

Current assignee appears busy.

r? rust-lang/compiler

[RalfJung]

Please type @rustbot ready once you want a review. Reviewers will generally not look at PRs that are still marked "waiting for author".

[shepmaster]

Didn't even realize it was in that state. It was moved there in #120808 (comment) and then immediately followed by a "oh maybe this still needs someone to look at it" style comment that didn't set it back.

@rustbot ready

[shepmaster]

Although I think that the "tied" terminology should be discussed before this merges, I expect that will just be a long giant bikeshed, so I'll go ahead and mark this as not a draft PR and then if someone "accidentally" merges it before that discussion, then we'll just have to live in that world.

[RalfJung]

If you make the lint unstable, you can delay that bikeshed until later. ;)

(Lints can be associated with a feature gate to make them unstable.)

[jieyouxu]

Although I think that the "tied" terminology should be discussed before this merges, I expect that will just be a long giant bikeshed, so I'll go ahead and mark this as not a draft PR and then if someone "accidentally" merges it before that discussion, then we'll just have to live in that world.

@shepmaster I'm going to lang-nominate this to be discussed, otherwise it will never happen if it's more of a "suggestion" that's not on team calendars/radars. Please feel free to edit my comment or post a more accurate summary for T-lang to consider.

---

Nominating for T-lang discussion: what should the split up elided_lifetimes_in_paths lints be called?

Reproducing parts of PR description below:

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.

@rustbot label +I-lang-nominated

[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.