Anon lifetime in impl Trait no longer suggests adding a lifetime parameter

[estebank]

Given fn foo(_: impl Iterator<Item = &u32>) {}.

In 1.63:

error[E0106]: missing lifetime specifier
 --> src/lib.rs:1:32
  |
1 | fn foo(_: impl Iterator<Item = &u32>) {}
  |                                ^ expected named lifetime parameter
  |
help: consider introducing a named lifetime parameter
  |
1 | fn foo<'a>(_: impl Iterator<Item = &'a u32>) {}
  |       ++++                          ++

In 1.64:

error[E0658]: anonymous lifetimes in `impl Trait` are unstable
 --> src/lib.rs:1:32
  |
1 | fn foo(_: impl Iterator<Item = &u32>) {}
  |                                ^

[apiraino]

WG-prioritization assigning priority (Zulip discussion).

@rustbot label -I-prioritize +P-high

[pnkfelix]

self-assigning to ensure we record a cargo-bisect to the injecting PR

[apiraino]

I went ahead and attempted a bisection. The breadcrumbs seem to lead to rollup of #99231 with possibly #97720 being the patchset where this issue originates cc @cjgillot ?

searched nightlies: from nightly-2022-07-13 to nightly-2022-07-15
regressed nightly: nightly-2022-07-15
searched commit range: 87588a2...c2f428d
regressed commit: f1a8854

bisected with cargo-bisect-rustc v0.6.3

Host triple: x86_64-unknown-linux-gnu
Reproduce with:

cargo bisect-rustc --start 2022-07-13 --end 2022-07-15 --preserve 

[spastorino]

I'm not sure what would be wrong after @cjgillot change. I think this is exactly the support Camille has added. If you use #![feature(anonymous_lifetime_in_impl_trait)] the example compiles and if you don't the error points to the anonymous lifetime and tells you that you would need the feature flag to support such case.

[cjgillot]

Added an explanation in #85417 (comment).
TLDR: I proposed to allow this syntax, we made a feature gate instead, and I forgot to put back the suggestion.

[apiraino]

Visited during last weeks' T-compiler meeting on Zulip, relaying Felix's comment here for visibility:

@cjgillot are you planning to put back the suggestion? Alternatively, do you think that might be a nice small task for a new contributor to pick up?

[cjgillot]

This should be an easy enough task for a new contributor. Summary instructions:

• the feature-gate error is emitted from rustc_resolve::late::lifetimes::resolve_lifetime_ref;
• the generics of the enclosing item can be accessed by tcx.hir().get_generics(lifetime_ref.hir_id.owner);
• if that generics struct is Some, this means the item can have generics, not that it actually has;
• the contained value is a hir::Generics, which should be analysed to know how to suggest: span contains the full <...> span, and params shows how many of them each with their own span;
• I recommend suggesting the additional lifetime parameter as the first one, to avoid questions about the order of lifetime/type/const parameters.

[Stoozy]

Hello, I would like to work on this. So far I've been able to get this kind of output

error[E0106]: missing lifetime specifier
 --> test.rs:1:32
  |
1 | fn foo(_: impl Iterator<Item = & u32>) {}
  |                                ^ expected named lifetime parameter
  |
help: consider introducing a named lifetime parameter
 --> test.rs:1:7
  |
1 | fn foo(_: impl Iterator<Item = & u32>) {}
  |       ^

with the input found in the original message.

I am looping over all generic params and checking if the full <...> span doesn't contain the span associated with the parameter, at which point I try to suggest the introduction of the named lifetime parameter.

I'm looking for a few pointers on:

• If my logic actually makes sense
• what other suggestions rustc_resolve::late::lifetimes::resolve_lifetime_ref should handle.
• how to properly emit the errors/suggestions (I see that late/diagnostics.rs also does similar suggestions but I'm unsure if/how I should use it)

[cjgillot]

@Stoozy could you open a PR with what you have and tag me? Discussing on code will be more concrete and easier.

[Rageking8]

@Stoozy Another friendly tip: when you want to undertake an issue, you should claim the issue first to prevent duplicated effort (Write the command shown below in the target issue as a comment to assign urself). Thanks.

[estebank]

@Stoozy can you call LateResolutionVisitor::suggest_introducing_lifetime (or split part of its body to make it appropriate for this case too) and reuse that logic?

[Stoozy]

@rustbot claim

[BGR360]

Closed by #102323? Or is there more to do?

[cjgillot]

Yes, closed by #102323, and #104048 will handle some suggestion corner cases.