Stop errorring for elided lifetimes in path.

[cjgillot]

This special case is used to ban elided lifetimes in path in async fns and impl block headers.
It does the same thing as the elided-lifetimes-in-paths lint, excepts as a hard error.

Having both flavours does not really bring anything but complexity.
This PR proposes to remove the special case.

This will allow to always use the CreateParameter mode for anonymous lifetimes in a later PR.

[rust-highfive]

r? @wesleywiser

(rust-highfive has picked a reviewer for you, use r? to override)

[bors]

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

[wesleywiser]

@jackh726 would you mind taking a look at this? Thanks!

r? @jackh726

[jackh726]

It's surprising that this change is only picked up in this test. I would have expected it to be picked up in a parsing or lowering test or something.

Regardless, this change will need a lang (probably) FCP. FWIW, I personally don't think allowing elided lifetimes in impl headers is the right move. It's 1) inconsistent with the general trend of not allow elided lifetime parameters and 2) unspecified on if it would be 'static (as is assumed today under error conditions or some new lifetime (which would be the case if you did '_.

[jackh726]

I'm also maybe a bit confused here. I guess the ELIDED_LIFETIMES_IN_PATHS lint is allow by default, but was erroring. Is that what you're cleaning up?

[cjgillot]

ELIDED_LIFETIMES_IN_PATHS is an allow-by-default lint, but some cases (impl headers and async fns) are hardcoded to be a (slightly different) error instead. As I understood, ELIDED_LIFETIMES_IN_PATHS is not close to being warn-by-default any time soon: too much of mechanical changes each time a lifetime is added/removed somewhere.

The goal of this PR is to simplify the implementation by having only one flavour of error. If relaxing the behaviour is not desirable, I will attempt to refactor the code to only have one implementation and one message.

[jackh726]

If relaxing the behaviour is not desirable

I think that is the case, yeah. We could poll the lang team, but given that the general trend seems to be more explicitness when there could be ambiguity (this error, dyn Trait instead of Trait, etc.), I would be surprised if this is direction we want to take.

It definitely does seem like there's some opportunity to clean this up though, even if we error or (maybe) lint depending on the context.