Meriyah does not properly follow ECMA standards on function declaration and calling.

[LumenUI]

When experimenting with Meriyah, I discovered the parser properly registers the following invalid function declarations and calls:

function 10() {
   return 10;
}

10();

function "string"() {
   return "string"();
}

"string"();

Meriyah also struggles when calling functions. It will assume that the name of the function being called is an identifier, and not a literal.

[3cp]

Probably missed check in

meriyah/src/common.ts

Line 391 in 3c0b156

export function validateFunctionName(

[3cp]

@KFlash what's this line doing?

meriyah/src/parser.ts

Line 4800 in 3c0b156

validateFunctionName(parser, context | ((context & 0b0000000000000000000_1100_00000000) << 11), parser.token);

It says (context & (Context.Strict | Context.Module)) << 11, the shifting 11 bits to the left which moves the strict and module context to InYieldContext and InAwaitContext. I have no idea why it does that.

[KFlash]

validates func names and remove module and strict check

[3cp]

Why shift 11 bits?

[3cp]

I think I missed the leading context | ... but I still don't understand the logic.

[KFlash]

then rewrite it. I guess that logic broke at some point where token.ts was updated with support for newer AST nodes

[3cp]

That logic was not the reason of this bug. I am just curious about the line which I still don't understand.

[KFlash]

The logic is - I think - is that await and yield has a value around 21? Then you shift to left so you can unset this masks. Doing so will let you validate cases that should be valid even in async or yield context

[3cp]

There are lots of missed rejection on CallExpression, for example:

["a"]();
var a = {a:1}();
null();
true();
false();

It's bit hard to clear up all of them, which leads me to think maybe our Flags.DisallowCall is not well fitted for its purpose.

I fixed all the above, but surely there are more (mainly in parsePrimaryExpression).

[3cp]

@KFlash some interesting finding. In real JS parser (nodejs), null(), true(), false() are not parser error, but runtime error.

function a() { null(); }
a(); // error throws on this line, not previous line

I guess we don't need to reject the 3 in parsing.

[3cp]

My lord "a"() is runtime error too.

function a() { "a"() }

This parses with no issue in browser or nodejs.

@KFlash I guess we don't change the rejections of CallExpression at all?

[3cp]

1() is runtime error too.

[3cp]

Other parsers like acorn and TS do not reject them.

[LumenUI]

Apologies.

[3cp]

@LumenUI nothing to be sorry for. It was a valid point, and very subtle and surprising behavior, which clarified some edge cases.

In fact, meriyah's behavior is still not same as native JS parser. []() and ({}()) are parsing time error (means even when wrapped inside function) but meriyah did not pick them up. I will open another issue to clean up that.

[3cp]

NVM, my mistake, []() and ({}()) is runtime error too :-)