Ambiguity between type ascription and absolute paths

[matklad]

I am not sure, but I think the following program should be valid:

type X = ();

fn main() {
    let ():::X = ();
}

It currently fails with

error: expected identifier, found `:`
 --> /home/matklad/tmp/main.rs:4:13
  |
4 |     let ():::X = ();
  |             ^ expected identifier

because we don't try to decompose :: token.

I am not sure what should be the behavior of

type X = ();

fn main() {
    let Y:::X = ();
}

but I lean towards allowing it as well, looks like it requires only constant look-ahead to handle.

Anyway, rg ':::' --type rust shows that we don't have a test here.

@petrochenkov what are your thoughts on this?

[matklad]

сс @rust-lang/wg-grammar

[petrochenkov]

what are your thoughts on this?

I was aware of this, but never planned making a fix due to low priority.
It's quite possible that some other multi-character punctuation is not broken into parts when it should.
As you could notice things like this are fixed on "on demand" basis.
Hopefully, issues like this will disappear as a class after migrating to the single-character punctuation model.

[Centril]

I am not sure, but I think the following program should be valid:

According to libsyntax (fn parse_path), the grammar is:

    /// `path = [::] segment+`
    /// `segment = ident | ident[::]<args> | ident[::](args) [-> type]`

A path cannot end with :: and so an identifier is correctly expected but not found.

I am not sure what should be the behavior of

Unless I'm missing something fundamental here, the same issue as above applies and this should remain an error.

[matklad]

@Centril I think you are trying to read this as :: :, while I read it as : :: I believe (): ::X and Y: ::X are unambiguous parses, it's just that the current implementation is to eager to eat ::.

I've checked with syn, and it parses the first example but not the second one.

[matklad]

Hopefully, issues like this will disappear as a class after migrating to the single-character punctuation model.

Yeah, that's exactly how I found this. My fear here though is that a genuine ambiguity might lurk in there...

[Centril]

@Centril I think you are trying to read this as :: :, while I read it as : :: I believe (): ::X and Y: ::X are unambiguous parses, it's just that the current implementation is to eager to eat ::.

Oh I see. What's the ambiguity referenced in the title then?

[matklad]

@Centril that was a non-formal use of the word, in a sense that rustc's parser can confuse the two. I am almost sure that there's no ambiguity on the grammar level here with tokens-with-jointness model, but I want to double check

[Centril]

@matklad I see. For now, I think it would be good to add a test documenting the current behavior to prevent accidents.

[GrigorenkoPV]

After #130673, the parser now recovers from ::: to just :: in some places. Not here though.