Enforce the comma after lifetime arguments and before type arguments

[bombless]

Closes#20616
It breaks code such as

rust/src/librustc_typeck/check/method/suggest.rs

Line 367 in c64feb6

borrow: cell::Ref<'a Option<AllTraitsVec>>,

, so this is a [breaking-change], you have to add missing comma after the last lifetime arguement now.

[rust-highfive]

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

[bombless]

I'm not sure about the performance impact of this bufferring.
I see I can modify parse_lifetimes to avoid this, but that will look unnatural.

[pnkfelix]

We may eventually need / want a help in the output reminding that 'a T is not a type, and suggesting either 'a, Tor&'a T, since we do not generally know which was intended

[pnkfelix]

Why are these tests commented out?

[pnkfelix]

Why are there nine compile-fail tests, with no header comment, that all appear similar (even duplicates?) based on a quick skim? Was that accidental?

[pnkfelix]

Hmm, shouldn't these tests be checking (perhaps in addition) all the same cases when parsing MyOtherType<'a>, with no type argument?

[pnkfelix]

Sorry that was phrased poorly; what I meant was that cases like Box <MyOtherType <'static>> etc need checking too, with the >> token after a lifetime, right?

[pnkfelix]

Ugh never mind again, you did check that, I just missed it twice

[bombless]

Because you cannot resume from parsing error, so I have to test different errors in separate files.

I'll try suggesting &'a T and 'a, T for 'a T here.

[bombless]

Oh yes these 9 compile-fail files are similar intentionally, the difference is just that only one parsing error is uncommented at once.

I'll add comments to make this clear.

[Manishearth]

technically a breaking change, might want to edit the PR message to reflect that

[bombless]

right. fixed.

I'm trying to make a different approach, which will make catching the > more natural, hope it can help to provide a good diagnostics note message.

Currently I'm using Parser::is_path_start but it doesn't seem to work here. I'll see what's missing here.

I think we cannot pretty-print a type this early, so I will just make the codemap feels right, and use the first token to generate a note, e.g. suggest "do you mean &'a Box... or 'a, Box..." for <'a Box<i32>> in code.

Or am I missing something?

Any suggestions, @pnkfelix ?

[pnkfelix]

@bombless oh yes, I do not object to being fairly generic in the help message; this would not be the first place that we've inserted GenericTypeName in a help message rather than trying to reconstruct it from the input.

[pnkfelix]

@bombless as for catching the leading >, I was musing: Would it be sensible to add a method to Token that tells us the first character in that token? Then you could just call out to that method...

[bombless]

Would it be sensible to add a method to Token that tells us the first character in that token?

Okay I'll do that.

[bombless]

Nits fixed, @pnkfelix

[bors]

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

[bombless]

rebased

[bombless]

oh yes, I do not object to being fairly generic in the help message; this would not be the first place that we've inserted GenericTypeName in a help message rather than trying to reconstruct it from the input.

Do you mean that there's other places in parser.rs need to print a generic type? I don't really understand this, sorry.

[pnkfelix]

@bombless Yeah, sorry, I can see that my use of the phrase "GenericType" can be easily misinterpreted there; it was the name I was referring to as being generic, not the type ...

That is, I was trying to say this:

• What you describe sounds roughly fine to me.

• After all, only some of our error messages take pains to try to generate an error message that is specifically tailored to match the names used in the original user code (such as when we suggest adding more explicit lifetimes).

  We do that sometimes.

• But we haven't always done it; sometimes the info is not available, and other times the developer doesn't have the time to try to make such a message construction work out.

  And that is okay.

• Here is an example of the kind of short-cut I am talking about; up until very recently, we would happily print out "perhaps you meant box() (foo) instead?" for code that did not mention foo at all, and that is okay.

• And therefore, I was saying it would be fine with me if your code took a similar short-cut; it would not be the first instance where we inserted foo in a help message rather than trying to reconstruct the actual expression from the input.

---

The main thing I would suggest is this: If you were literally suggesting that when <'a Box<i32>> is what is in the original code, your help output would print:

do you mean &'a Box... or 'a, Box...?

then I advise that you not use ellipses in that fashion, but instead use a placeholder name for the type that you cannot print. Like so:

did you mean &'a Box<Type> or 'a, Box<Type>?

where Type is being used (in the help output) as a placeholder name for the type that we have not yet parsed.

Update: Then again, maybe it is not feasible to attempt to try to plug in placeholders into the type arguments for Box in this example. In which case I would go even further and suggest that you render the help message as:

did you mean a single argument type &'a Type, or did you mean the comma-separated arguments 'a, Type

Update 2: In some ways the english text prefixing to the two suggestions in this final example output is just as important, or perhaps more important, than the suggestion itself, in that (I hope) it makes it much clearer why there is an ambiguity here as to what the original intent of the user was.

[pnkfelix]

@bors r+ 0ad48e4 rollup

[bors]

⌛ Testing commit 0ad48e4 with merge 00c48d3...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-32-nopt-t, auto-win-32-opt, auto-win-64-nopt-t, auto-win-64-opt

[pnkfelix]

(potential future cleanup: maybe just get rid of the commented out cases in all the tests...)

[pnkfelix]

accepted for beta backport.

[brson]

Backported.