[webkit-reviews] review requested: [Bug 194095] [JSC] Add support for static public class fields : [Attachment 404092] Add support for static public fields, v4

[bugzilla-daemon at webkit.org]

Xan Lopez <xan.lopez at gmail.com> has asked  for review:
Bug 194095: [JSC] Add support for static public class fields
https://bugs.webkit.org/show_bug.cgi?id=194095

Attachment 404092: Add support for static public fields, v4

https://bugs.webkit.org/attachment.cgi?id=404092&action=review




--- Comment #6 from Xan Lopez <xan.lopez at gmail.com> ---
Created attachment 404092

  --> https://bugs.webkit.org/attachment.cgi?id=404092&action=review

Add support for static public fields, v4

New version.

Fixed two of the failing V8 tests, a few other naming fixes, rebased against
master.

There is one remaining V8 failure, but I think this is not a field bug per se,
just the new code finding an old issue. Basically:

 let q = { ["z"]: class { static y = this.name } }
 assertEquals(q.z.y, 'z');

This will fail (the value of q.z.y is ''). The reason is that the existing code
sets the function name for the class *after* the whole class is generated. The
spec says it should happen within the class definition evaluation (see 14.6.14
Runtime Semantics: ClassDefinitionEvaluation). This was perhaps mostly harmless
until now, but with static fields the initializer runs before the class
evaluation is over, so it finds 'this.name' to be unitialized. This would work
for a non-computed property name (z: class { ... }) because in that case the
parser itself will already set the proper function name, but for computed
property names that does not happen. I will open a follow-up for this issue if
we agree it should be fixed in parallel.