Parser does not stop early enough if keyword is found instead of ident

[nagisa]

For

enum A {
    enum A
}

and for

struct A {
    mod A
}

2 errors are emitted for each

test.rs:2:5: 2:9 error: expected identifier, found keyword `enum`
test.rs:2     enum A
              ^~~~
test.rs:2:10: 2:11 error: expected one of `(`, `,`, `=`, `{`, or `}`, found `A`
test.rs:2     enum A
                   ^

and

test.rs:2:5: 2:8 error: expected identifier, found keyword `mod`
test.rs:2     mod A
              ^~~
test.rs:2:9: 2:10 error: expected `:`, found `A`
test.rs:2     mod A
                  ^

2nd error should not happen.

[nagisa]

Note that neither of these print a

error: aborting due to previous error

which would be a case if it terminated in properly.

[nagisa]

More:

test.rs:2:9: 2:12 error: expected identifier, found keyword `mod`
test.rs:2     let mod hello;
                  ^~~
test.rs:2:13: 2:18 error: expected one of `:`, `;`, `=`, or `@`, found `hello`
test.rs:2     let mod hello;
                      ^~~~~

[matklad]

The problem is that check_strict_keywords, unlike check_reserved_keywords, does not return a PResult. In rustc, this function is used only once in parse_indent. However, this is a public fn, so it might be used outside rustc.

Is it safe to change this function interface?

[nagisa]

All functions exposed from the rustc libraries are unstable.

[matklad]

I wonder whether this is a bug or an expected behavior.

There is a test parse-fail/keywords-followed-by-double-colon:

fn main() {
    struct::foo();  //~ ERROR expected identifier
    mut::baz(); //~ ERROR expected identifier
}

Looks like reporting two errors here is a good thing.

[alexcrichton]

Discussed on #28444, and the conclusion was that this is currently intended behavior, so closing as working-as-intended.