Split elided_lifetime_in_paths into finer-grained lints

[shepmaster]

Description

Converts the existing elided_lifetime_in_paths lint into three smaller pieces:

• hidden_lifetimes_in_input_paths — fires for fn(ContainsLifetime) -> ...
• hidden_lifetimes_in_output_paths — fires for fn(...) -> ContainsLifetime
• hidden_lifetimes_in_type_paths — fires for many other usages of ContainsLifetime, such as in a static or in a turbofish

A new group hidden_lifetimes_in_paths is created with the three smaller lints and places that use the old elided_lifetime_in_paths name are updated to match.

#![allow(dead_code)]
#![warn(hidden_lifetimes_in_paths)]

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

fn inputs_and_outputs(v: ContainsLifetime) -> ContainsLifetime { v }
static CL: ContainsLifetime = ContainsLifetime(&42);

fn main() {}

warning: paths containing hidden lifetime parameters are deprecated
 --> a.rs:6:26
  |
6 | fn inputs_and_outputs(v: ContainsLifetime) -> ContainsLifetime { v }
  |                          ^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(hidden_lifetimes_in_input_paths)]` implied by `#[warn(hidden_lifetimes_in_paths)]`
help: indicate the anonymous lifetime
  |
6 | fn inputs_and_outputs(v: ContainsLifetime<'_>) -> ContainsLifetime { v }
  |                                          ++++

warning: paths containing hidden lifetime parameters are deprecated
 --> a.rs:6:47
  |
6 | fn inputs_and_outputs(v: ContainsLifetime) -> ContainsLifetime { v }
  |                                               ^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(hidden_lifetimes_in_output_paths)]` implied by `#[warn(hidden_lifetimes_in_paths)]`
help: indicate the anonymous lifetime
  |
6 | fn inputs_and_outputs(v: ContainsLifetime) -> ContainsLifetime<'_> { v }
  |                                                               ++++

warning: paths containing hidden lifetime parameters are deprecated
 --> a.rs:7:12
  |
7 | static CL: ContainsLifetime = ContainsLifetime(&42);
  |            ^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(hidden_lifetimes_in_type_paths)]` implied by `#[warn(hidden_lifetimes_in_paths)]`
help: indicate the anonymous lifetime
  |
7 | static CL: ContainsLifetime<'_> = ContainsLifetime(&42);
  |                            ++++

Background

In general, we want to discourage function signatures like fn (&T) -> ContainsLifetime, fn (ContainsLifetime) -> &T , and fn (ContainsLifetime) -> ContainsLifetime as it is not obvious that a lifetime flows through the function and back out as there is no visual indication that ContainsLifetime has a lifetime generic (such types are not usually literally called "contains lifetime" 😃).

In #120808 (comment) (and multiple followup comments, e.g. #120808 (comment)), the lang team decided on a plan where we introduce a new lint which helps insure consistency between input and output lifetime syntaxes and then split elided_lifetime_in_paths into three parts. The combination of these lints should be enough to accomplish the original goal.

History

Note that this PR has substantially changed from its original version. Check the (copious) comments below as well as the edit history of this message.

[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 #142442) made this pull request unmergeable. Please resolve the merge conflicts.

[shepmaster]

r? @jieyouxu

[rustbot]

Changes to the size of AST and/or HIR nodes.

cc @nnethercote

[nnethercote]

Ah, this is unfortunate. Ty is a very common type, an extra 8 bytes just to fit a boolean?

[jieyouxu]

I'll take an initial look at this approx. this Wednesday.
@rustbot label -S-waiting-on-team