Parser allows 'let' as a variable name

[aapoalas]

Both lines of the following code should be syntax errors but are not:

const let = 3;
for (const let in {}) { }

[Boshen]

The parser doesn't throw all syntax errors, you need to run semantic as well.

https://github.com/oxc-project/oxc/blob/7eb286413e6f7b4f6c2705685b3114ce97498578/crates/oxc_semantic/src/checker/javascript.rs#L146-L149

The parser is sort of like fast mode, all heavier checks are deferred to the optional slower semantic builder, for different use cases.

Please let me know if you need any changes to make things a little bit easier for Nova.

[aapoalas]

Ah, hum. Sorry about the noise then. Is there any concrete rules for when something is semantics and when it is parsing? eg. Why is const as variable name a parser error but let is not?

[Boshen]

There were no rules for it. Things were moved out of the parser if

• its slow or on the hot path
• requires more complex state tracking
• requires parent ast node lookup

[aapoalas]

Hmm. At least in this specific case I'd expect both const let = 3 and let const = 3 to either both or neither to be errors in the parser. Right now let const = 3 is but the other isn't. I would presume there is no performance difference between checking the two after all.

[Boshen]

We can move some of these checks back to the parser.

[armano2]

important to read before implementing this: ref https://tc39.es/ecma262/#sec-keywords-and-reserved-words js has few reserved words that can't be used as variables,

let is technically allowed (sometimes) in non strict mode

[Boshen]

Took another look at this. Nova engine should report its own syntax errors if oxc doesn't report them from oxc_parser, as they require tracking context (such as strict mode).