Add tests for completion value of function / class declaration statements

[JosephPecoraro]

Check completion value of more declarations are empty:

eval(`1; function f(){}`) === 1
eval(`1; function* f(){}`) === 1
eval(`1; async function f(){}`) === 1
eval(`1; class C {}`) === 1

Browsers:

• Firefox passes all
• Chrome fails for class - bug
• WebKit fails for class - bug
• Edge fails for class - bug

[littledan]

Thanks for the contribution! Keep them coming.

It looks from the specification that the completion value of class declarations is the constructor, rather than empty. Because of this, I think Firefox is the engine with a bug, rather than the other three.

[anba]

It looks from the specification that the completion value of class declarations is the constructor, rather than empty.

No, an empty completion value is correct -> https://tc39.github.io/ecma262/#sec-class-definitions-runtime-semantics-evaluation.

[littledan]

Oh sorry, I was looking at ClassExpression.

[leobalter]

The tests are looking good for me. I appreciate you're following the file naming pretty well.

There's a small detail to be fixed in the frontmatter (see the other comments).

You may also add a test for async generator declaration (adding the features: [async-iteration] frontmatter tag, or we can work on that as a follow up.

[leobalter]

use esid instead of es6id, please:

esid: sec-async-function-definitions-runtime-semantics-evaluation

[leobalter]

use esid instead of es6id, please:

esid: sec-class-definitions-runtime-semantics-evaluation

[leobalter]

use esid instead of es6id, please:

esid: sec-function-definitions-runtime-semantics-evaluation

[leobalter]

use esid instead of es6id, please:

esid: sec-statement-semantics-runtime-semantics-evaluation

[JosephPecoraro]

You may also add a test for async generator declaration (adding the features: [async-iteration] frontmatter tag, or we can work on that as a follow up.

I would rather someone address this in a follow-up. Its not in the current ES spec, and it looks like it does not behave like other declarations, and instead returns the function instead of an empty completion like all of these declarations. See https://tc39.github.io/proposal-async-iteration/#prod-AsyncGeneratorDeclaration

AsyncGeneratorDeclaration : async [no LineTerminator here] function* BindingIdentifier ( FormalParameters ) { AsyncGeneratorBody }

...
3. Let F be ! AsyncGeneratorFunctionCreate(Normal, FormalParameters, AsyncGeneratorBody, scope, strict).
...
7. Return F.

[leobalter]

I would rather someone address this in a follow-up

This is fine.

Its not in the current ES spec, ...

This is tricky. Test262 capture tests not only for the current spec draft, but also stage 3 proposals. The motivation is allowing runtimes to implement correct features before Stage 4.

Anyway, that doesn't make any requirement to land everything together, but it opens an reminder we should cover async generators as well. I'll create an issue to keep track.

Thanks for the tests!

[littledan]

@JosephPecoraro I see that text, but it looks like it's under the heading Runtime Semantics: InstantiateFunctionObject.

If you look at the 8th bullet of this section, it mentions adding a clause for evaluation analogous to GeneratorDeclaration, which evaluates to NormalCompletion(empty). So I believe async generators should have an empty completion value just like other types of declarations.

Anyway, putting this test in a follow-on patch sounds good to me.

EDIT: I was unclear on the specification at first; the above comment is more relevant.

[JosephPecoraro]

Test262 capture tests not only for the current spec draft, but also stage 3 proposals.

I didn't realize that. Thanks for the clarification.

If you look at the 8th bullet of this section, it mentions adding a clause for evaluation analogous to GeneratorDeclaration, which evaluates to NormalCompletion(empty). So I believe async generators should have an empty completion value just like other types of declarations.

Ahh, I see. Thanks.