Support generic lifetime arguments in method calls

[petrochenkov]

Fixes#42403
Fixes#42115
Lifetimes in a method call x.f::<'a, 'b, T, U>() are treated exactly like lifetimes in the equivalent UFCS call X::f::<'a, 'b, T, U>.
In addition, if the method has late bound lifetime parameters (explicit or implicit), then explicitly specifying lifetime arguments is not permitted (guarded by a compatibility lint).
[breaking-change] because previously lifetimes in method calls were accepted unconditionally.

r? @eddyb

[eddyb]

cc @nikomatsakis Whom I've discussed this with previously.

So I'm not sure I still have them somewhere, but I've done a crater run on a stricter version of this (just banning lifetimes) and found a few problems, mostly related to the fact that late-bound lifetimes do not appear in ty::Generics. I'm not even sure it's a good idea to expose the distinction.

There were some ideas to prevent explicit lifetimes when any ended up being late-bound, or outright support them (after #42417 we could start playing with that idea).

[nikomatsakis]

So I am pretty nervous about exposing only the early-bound lifetimes. This ties in to that other issue, where we do allow such regions sometimes. I really would prefer it we only allow users to manually specify regions when they are all early-bound, so we can do it realiably and in a clearly forwards compatible way.

[petrochenkov]

only allow users to manually specify regions when they are all early-bound, so we can do it realiably and in a clearly forwards compatible way

I'll implement this then for both method calls and UFCS as a deny-by-default lint for cratering.

[nikomatsakis]

Discussed in the @rust-lang/lang meeting -- we agree that restricting to 100% early-bound is the right thing here.

[alexcrichton]

ping @petrochenkov, just wanted to keep this on your radar!

[bors]

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

[petrochenkov]

I've almost submitted an update implementing #42492 (comment), but then realized that late bound lifetime parameters can be defined implicitly through lifetime elision (e.g. fn f(_: &u8) {}).
@eddyb Is there an easy way to detect presence of such implicit parameters during type checking? I haven't investigated yet.

[eddyb]

You can detect them but I wouldn't consider them parameters for the purposes of paths, as I wouldn't an impl Trait somewhere in an argument type.

[petrochenkov]

@eddyb

I wouldn't consider them parameters for the purposes of paths

It's just strange that these two functions are identical

fnlate_explicit<'early,'late>(_:&'lateu8) -> &'earlyu8{loop{}}fnlate_implicit<'early>(_:&u8) -> &'earlyu8{loop{}}

, but late_implicit::<'static> would be legal and late_explicit::<'static> would be not. Writing out the late bound lifetime explicitly would be a breaking change then.

(I suppose turning impl Trait into an explicit parameter shouldn't be a breaking change as well, because it's going to happen all the time.)

[eddyb]

IMO there is no other real choice if we want the explicitly written parameters to mean anything.

[petrochenkov]

if we want the explicitly written parameters to mean anything.

I'm not sure what do you mean.

(I'm still going to check for implicit parameters, at least to look at what crater will say.)

[eddyb]

@petrochenkov I meant that I don't think we can reasonably let you write anything other than what is present between <...> syntactically in the definition of the item, in a path to that item.

But I suppose I'm okay with going the even more conservative route of banning explicit parameters of a certain kind when there are implicit ones of that kind which could be later made explicit.

[petrochenkov]

I believe I've extracted all the necessary logic to catch late bound parameters from resolve_lifetime.rs.
This should be ready for crater now.

(There's also an interesting case with lifetimes in struct/variant constructors which are currently treated as early bound (#30904), but I haven't touched it, only added a test.)

[eddyb]

Started crater run.

[eddyb]

Crater run failed due to the inclusion of rustfmt in the build.

cc @rust-lang/dev-tools

[eddyb]

@petrochenkov Started another crater run.

[eddyb]

Third crater report shows 4 regressions.
Since the information was never used, I'm not sure why the authors kept the lifetimes (but really, it's our fault for parsing and ignoring them, some of them could be just "documentation").
There is at least one regression in unsafe code, which could potentially mean an invariant wasn't really enforced, but function signatures should prevent a real problem from spreading.

[Mark-Simulacrum]

I guess this is waiting on review? Or perhaps a decision from the lang team?

[nikomatsakis]

I think the relevant decisions have all been made -- we want to limit explicit lifetimes to cases that have only early-bound lifetimes for now (which are clearly backwards compatible). However, I'm not sure of the current back-and-forth between @eddyb and @petrochenkov on the state of the PR itself, it seems like they are iterating on crater runs.

As an aside, @brson has been complaining to me that people still use crater, and suggesting that we should try to do some cargobomb runs for better coverage. @brson-- who should be ping to try and get that going?

[petrochenkov]

@nikomatsakis

However, I'm not sure of the current back-and-forth between @eddyb and @petrochenkov on the state of the PR itself, it seems like they are iterating on crater runs.

The iteration is complete, all found regressions and mistakes are fixed.

[nikomatsakis]

I skimmed mostly, given that there has been so much back and forth, but this looks good to me. r=me once we change to warn-by-default (I expect this is what was intended, right?)

[nikomatsakis]

Do we really want to default to Deny here?

[petrochenkov]

The lint level is changed to warn-by-default.
@bors r=nikomatsakis

[bors]

📌 Commit 39114f9 has been approved by nikomatsakis

[bors]

⌛ Testing commit 39114f9 with merge 7c758abdad01aaa219c2cb14e4ed6878fb69c236...

[bors]

💔 Test failed - status-travis

[alexcrichton]

@bors: retry

• curl failure

[bors]

⌛ Testing commit 39114f9 with merge 29d60228266412b6bee73098d00ef185d781a8f3...

[bors]

💔 Test failed - status-travis

[est31]

@bors retry

[bors]

⌛ Testing commit 39114f9 with merge 83c659e...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing 83c659e to master...