Confusing error message: "expected 2 lifetime parameters"

[mark-i-m]

This code:

pub fn cli_args() -> clap::App<'_, '_> {
    clap_app! {foo =>
        (about: "foo the bar.")
    }
}

Gives me the following error:

error[E0106]: missing lifetime specifiers
  --> src/analysis.rs:10:32
   |
10 | pub fn cli_args() -> clap::App<'_, '_> {
   |                                ^^ expected 2 lifetime parameters

But I do have 2 lifetime parameters?

[estebank]

CC #60199 which shows how you can easily end with this code thanks to compiler suggestions.

I believe the parser is unifying the two lifetimes as one because they have the same name. @nikomatsakis was this intended? I was under the impression that multiple uses '_ would always introduce a new lifetime. The fix is either for changing the current behavior to accept this code, or fix the diagnostics and suggestions to explain the need for named lifetimes in this case.

[estebank]

It does seem like accepting only one '_ lifetime was intentional:

rust/src/librustc/middle/resolve_lifetime.rs

Lines 2204 to 2208 in e938c2b

	let elide = if lifetime_count == 1 {
	Elide::Exact(possible_implied_output_region.unwrap())
	} else {
	Elide::Error(arg_lifetimes)
	};

[mark-i-m]

In that case, the error just needs to be updated to say "only one elided lifetime is allowed" or something. But I'm very curious why that is the case.

[mark-i-m]

Hmm... also what are the odds that the same error was reported less than a day ago? Is this a regression or has it always done this?

[estebank]

Changing the code I linked above to be Elide::FreshLateAnon(Cell::new(lifetime_count as u32)) with the following code

struct S<'a, 'b> {
    a: &'a usize,
    b: &'b usize,
}

fn foo() -> S<'_, '_> {
    unimplemented!();
}
fn main() {
}

emits the following output (and changes some existing tests' output the same way)

error[E0581]: return type references an anonymous lifetime which is not constrained by the fn input types
 --> file.rs:6:13
  |
6 | fn foo() -> S<'_, '_> {
  |             ^^^^^^^^^
  |
  = note: lifetimes appearing in an associated type are not considered constrained

---

Is this a regression or has it always done this?

It's always been the case since stabilization in 1.26, and probably since Jan 2017 when the code was originally written. My guess would be the "hidden lifetime parameters in types are deprecated" landing recently causing this type of code more likely to appear due to suggestions.

---

I believe that this can be solved as a simple diagnostics fix, but am intrigued at how to communicate why S<'_, '_> isn't valid (sure, we can say that it is hard to decide what lifetime goes with what, but it sounds like a cop-out).

[mark-i-m]

There is always that compiler buzzword: ambiguous 😛

[estebank]

There is always that compiler buzzword: ambiguous

me: writes code
rustc: 🤷ZWJ🦀

[joelparkerhenderson]

Similar issue, also because of clap.

The Rust compiler suggested this:

help: try adding a return type
... clap::app::App<'_, '_> {

If I understand the above discussion, then the compiler suggestion will fail, because of multiple elision. Can the compiler suggestion be adjusted?

[estebank]

@joelparkerhenderson we do so when possible, but it is considered acceptable (at the very least tolerated) if a suggestion gives you wrong code that a subsequent compilation will receive a new suggestion that does get you to working code.

[kadiwa4]

The error message is helpful now (nightly 2023-01-15, clap 2.34.0):

error[E0106]: missing lifetime specifiers
 --> lib.rs:3:32
  |
3 | pub fn cli_args() -> clap::App<'_, '_> {
  |                                ^^  ^^ expected named lifetime parameter
  |                                |
  |                                expected named lifetime parameter
  |
  = help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
help: consider using the `'static` lifetime
  |
3 | pub fn cli_args() -> clap::App<'static, 'static> {
  |                                ~~~~~~~  ~~~~~~~