gccrs incorrectly parses a fake turbofish operator

[liamnaddell]

Summary

not<true>(); should actually be written as not::<true>();, i.e. a turbofish operator. It seems though that this survives the parsing phase.

Reproducer

I tried this code:

fn not<const A: bool>() {
    let _ = if A
        { "A" }
    else
        { "B" }
    ;
}

fn main() {
    not<true>();
}

Does the code make use of any (1.49) nightly feature ?

• Nightly

Godbolt link

No response

Actual behavior

TRS-E14 cgen $ gccrs main.rs
main.rs:2:16: error: Cannot find path ‘A’ in this scope [E0433]
    2 |     let _ = if A
      |                ^

Expected behavior

TRS-E14 cgen :( $ rustc main.rs
error: comparison operators cannot be chained
  --> main.rs:10:8
   |
10 |     not<true>();
   |        ^    ^
   |

GCC Version

b87fd67

[powerboat9]

I've reduced the testcase to this, which only errors with rustc

#[cfg(foo)]
fn foo() {
    not<true>();
}

fn main() {}

It does look like rustc has a parse-time check for chained comparisons, while we only catch it incidentally at typechecking

[liamnaddell]

I guess gccrs parses this as (not < true) > (), where () is an empty tuple. I originally reported this as a parse error because I assumed this code would be totally invalid syntax.