tc39 / proposal-class-fields

Orthogonally-informed combination of public and private fields proposals
https://arai-a.github.io/ecma262-compare/?pr=1668
1.72k stars 113 forks source link

Inferred function names for number/bigint fields aren't handled right #314

Closed jswalden closed 4 years ago

jswalden commented 4 years ago

SpiderMonkey got a bug report about inferred names for bigint fields.

On semi-careful inspection of the spec, it appears that the SetFunctionName function to name anonymous functions that are assigned to numeric fields is wrong. Field definition evaluation stores a number or bigint for numeric fields, in the [[Name]] field. DefineField passes that value unaltered to SetFunctionName. And SetFunctionName asserts the provided name is Symbol, String, or Private Name.

Either that, or I skimmed too hard and too fast.

Probably the name-value should be converted to some canonical representation in field definition evaluation? I dunno, I'm not versed in this stuff enough to be sure.

jswalden commented 4 years ago

And to be clear, these are two testcases that should hit this omission:

class C66 {
    128n = class {};
}
new C66();

and

class C66 {
    128 = class {};
}
new C66();

(Possibly the spec does not require the final new expressions.)

jswalden commented 4 years ago

I skimmed too fast -- LiteralPropertyName evaluates to a string, not to potentially a numeric value.