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.

[bors]

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

[shepmaster]

@pnkfelix I'd like to request your assistance in figuring out what next steps I need to make to get this merged.

[shepmaster]

Addressed @estebank's concerns in this force push.

[estebank]

still looking, but publishing some stray comments

[bors]

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

[shepmaster]

Force pushed to try and fix the build and then another force push to address the conflict.

[shepmaster]

Another force push to address test failures.

[bors]

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