Correctly parse higher-ranked trait bounds

[aochagavia]

The function below:

fn test<F>(f: F)
where
    for<'a> F: Fn(&'a str)
{
    f("hello");
}

Produces a bunch of errors:

As you can see in the following AST:

ROOT@[0; 76)
  FN_DEF@[0; 23)
    FN_KW@[0; 2)
    WHITESPACE@[2; 3)
    NAME@[3; 7)
      IDENT@[3; 7) "test"
    TYPE_PARAM_LIST@[7; 10)
      L_ANGLE@[7; 8)
      TYPE_PARAM@[8; 9)
        NAME@[8; 9)
          IDENT@[8; 9) "F"
      R_ANGLE@[9; 10)
    PARAM_LIST@[10; 16)
      L_PAREN@[10; 11)
      PARAM@[11; 15)
        BIND_PAT@[11; 12)
          NAME@[11; 12)
            IDENT@[11; 12) "f"
        COLON@[12; 13)
        WHITESPACE@[13; 14)
        PATH_TYPE@[14; 15)
          PATH@[14; 15)
            PATH_SEGMENT@[14; 15)
              NAME_REF@[14; 15)
                IDENT@[14; 15) "F"
      R_PAREN@[15; 16)
    WHITESPACE@[16; 18)
    WHERE_CLAUSE@[18; 23)
      WHERE_KW@[18; 23)
      err: `expected a block`
  WHITESPACE@[23; 29)
  err: `expected an item`
  ERROR@[29; 32)
    FOR_KW@[29; 32)
    err: `expected an item`
  ERROR@[32; 33)
    L_ANGLE@[32; 33)
    err: `expected an item`
  ERROR@[33; 35)
    LIFETIME@[33; 35) "'a"
    err: `expected an item`
  ERROR@[35; 36)
    R_ANGLE@[35; 36)
  WHITESPACE@[36; 37)
  MACRO_CALL@[37; 38)
    PATH@[37; 38)
      PATH_SEGMENT@[37; 38)
        NAME_REF@[37; 38)
          IDENT@[37; 38) "F"
          err: `expected EXCL`
          err: `expected `{`, `[`, `(``
          err: `expected SEMI`
          err: `expected an item`
  ERROR@[38; 39)
    COLON@[38; 39)
  WHITESPACE@[39; 40)
  MACRO_CALL@[40; 51)
    PATH@[40; 42)
      PATH_SEGMENT@[40; 42)
        NAME_REF@[40; 42)
          IDENT@[40; 42) "Fn"
          err: `expected EXCL`
    TOKEN_TREE@[42; 51)
      L_PAREN@[42; 43)
      AMP@[43; 44)
      LIFETIME@[44; 46) "'a"
      WHITESPACE@[46; 47)
      IDENT@[47; 50) "str"
      R_PAREN@[50; 51)
      err: `expected SEMI`
  WHITESPACE@[51; 53)
  err: `expected an item`
  ERROR@[53; 74)
    L_CURLY@[53; 54)
    WHITESPACE@[54; 60)
    IDENT@[60; 61) "f"
    L_PAREN@[61; 62)
    STRING@[62; 69)
    R_PAREN@[69; 70)
    SEMI@[70; 71)
    WHITESPACE@[71; 73)
    R_CURLY@[73; 74)
  WHITESPACE@[74; 76)

[aochagavia]

@matklad do we have a place to track current language support? If there are other unsupported syntax constructs maybe we should create a tracking issue where we can list all of them.

[matklad]

If there are other unsupported syntax constructs maybe we should create a tracking issue where we can list all of them.

Fixing parser usually takes approximately the the same amount of work as logging the issue, the hard part is figuring out what's wrong. Hopefully, grammar working group will produce a comprehensive test suite.

Though, just logging a "parser error" issue with the code in question is helpful!

[matklad]

To rephrase this a bit, the core issue is that we need to have a comprehensive test suite. I suggest just waiting for it to appear, and in meanwhile just fix bugs as we see them. If no test-suite appears, we could make one using IntelliJ's parser.

[aochagavia]

Another way to test would be to parse well-known big Rust crates and see if the parser produces any errors. In theory, no errors should appear, right? Or do we want to test more than "the parser didn't produce any errors"?

[matklad]

Yep, that would also be a good step!

[DJMcNab]

I wonder if we could reuse some of the code from crater itself. I imagine it's made in a way that would allow us to use a custom process on each crate, rather than being limited to cargo check and test