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 warn-by-default lint mismatched_lifetime_syntaxes (superseding elided_named_lifetimes) 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]

Thanks for pushing this forward! ❤️

[jieyouxu]

r? @oli-obk (for a second opinion, unless you're busy)

[briansmith]

The tests should include the following cases as well, with the lints enabled:

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

impl ContainsLifetime<'_> {
   fn self_borrowed_self_output(&self) -> Self { unimplemented!() }
   fn self_moved_output(self) -> Self { self }
   fn self_another_borrowed_self_output(self, _: &u8) -> Self { self }
   fn self_input(&self, _: &Self) { }
   fn self_arbitrary(self: Self) { }
   fn self_arbitrary_self(self: Self) -> Self { self }
}

This will prevent us from accidentally changing whether Self is considered to have hidden lifetimes.

[cjgillot]

Can we avoid having this enum and have the lint compute where the type appears?

[oli-obk]

Specifically: you can look at the parent, or implement the lint on paths and look at the first segment

[shepmaster]

I don't know how to do this to achieve the goals. Interested parties can watch as I flail about over in Zulip.

[bors]

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

[oli-obk]

@rustbot author

[rustbot]

These commits modify the Cargo.lock file. Unintentional changes to Cargo.lock can be introduced when switching branches and rebasing PRs.

If this was unintentional then you should revert the changes before this PR is merged.
Otherwise, you can ignore this comment.

Some changes occurred in need_type_info.rs

cc @lcnr

HIR ty lowering was modified

cc @fmease

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[shepmaster]

@rustbot ready

[traviscross]

Suggested change

	indicate the anonymous lifetime
	indicate the inferred lifetime

I'd probably say "inferred" here for a couple reasons. One, I'm planning to update the Reference to call this the inferred lifetime (as we call _ the inferred type/const). Two, the lifetime isn't necessarily anonymous. It could be inferred to be a named lifetime, though of course we lint against that separately.

[traviscross]

Suggested change

	/// The `hidden_lifetimes_in_output_paths` lint detects the use
	/// of hidden lifetime parameters in types occurring as a function
	/// return value.
	/// The `hidden_lifetimes_in_output_paths` lint detects use of
	/// hidden lifetime parameters in the return type of a function.

[traviscross]

Suggested change

	/// Hidden lifetime parameters can make it difficult to see at a
	/// glance that borrowing is occurring. This is especially true
	/// when a type is used as a function's return value: lifetime
	/// elision will link the return value's lifetime to an argument's
	/// lifetime, but no syntax in the function signature indicates
	/// that.
	/// Hidden lifetime parameters can make it difficult to see at a
	/// glance that borrowing is occurring. This is especially true
	/// when the return type of a function hides a lifetime. Lifetime
	/// elision will link the lifetime in the return type to an input
	/// lifetime without any indication of this in the signature.

(This is to clean up (or avoid) some terminology around types/values and arguments/parameters.)

[traviscross]

Suggested change

	/// The `hidden_lifetimes_in_type_paths` lint detects the use of
	/// hidden lifetime parameters in types not part of a function's
	/// arguments or return values.
	/// The `hidden_lifetimes_in_type_paths` lint detects the use of
	/// hidden lifetime parameters in types other than those used
	/// within parameters or within the return type of a function.

[traviscross]

We're still staying "deprecated" here. While at some level I do think that's correct, I'd highlight the comment by @tmandry that @jieyouxu highlighted above; there'd need to be a reply to this to argue for why it should be kept. We would almost certainly get pushback on this language.

[traviscross]

Since this thread has become long and there were multiple FCP proposals, I'll mention for @oli-obk's convenience the one we're reviewing this against is #120808 (comment).