[Bug]: Code generated by Babel for decorated static accessors throws SyntaxError in Firefox about babel HOT 16 CLOSED

An even minimal example is

let capturedPrivateAccess;
class A {
  static #x = 42;
  static [(class {}, capturedPrivateAccess = () => A.#x)];
}
console.log(capturedPrivateAccess())

the class in the computed key is needed, but the private access doesn't need to be inside the class

from babel.

I think that is the same bug. Chrome doesn't throw because the function is never called.

from babel.

It seems like wrapping the computed key in an IIFE works:

let capturedPrivateAccess;
class A {
  static #x = 42;
  static [(() => (class {}, capturedPrivateAccess = () => A.#x))()];
}
console.log(capturedPrivateAccess())

from babel.

Even smaller reproduction, from Firefox folks :)

class A {
  static #x = 42;
  static [class {}];
} 

This throws in Firefox.

from babel.

This code on the other hand works:

class A {
  static [class A {}];
  static #x = 42;
}

Maybe this hints at a better fix than wrapping in an IIFE 🤔

from babel.

This code on the other hand works:

class A {
  static [class A {}];
  static #x = 42;
}

Maybe this hints at a better fix than wrapping in an IIFE 🤔

Well the decorator transform already output the class in the first static property.

from babel.

SpiderMonkey just merged a fix for this, but let's still implement a workaround plugin for all the existing Firefox version. @JLHwung do you want to work on it since you are fixing other decorator bugs, or should I do it?

Thank you. The bugfix is your idea, go ahead, meanwhile I will be kept busy by a few other decorators bugs.

from babel.

Hey @SirPepe! We really appreciate you taking the time to report an issue. The collaborators on this project attempt to help as many people as possible, but we're a limited number of volunteers, so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack community that typically always has someone willing to help. You can sign-up here for an invite.

from babel.

Yes, I am almost sure that this is a FF bug, both JSC and V8 work as expected.

Here is a minimal test case without any Babel helpers or the decorator boilerplates. It should print 42, currently it throws on FF but works on both JSC and V8:

let capturedPrivateAccess;
class A {
  static #x = 42;
  static [class B {
    static {
      capturedPrivateAccess = (t) => t.#x
    }
  }];
}
console.log(capturedPrivateAccess(A))

It seems to me FF somehow marks the whole computed key as if it were defined in the outer scope, this is convenient for the functional context variables such as this and super, but not the case for private environment where the #x should have been resolved.

Per spec RS:ClassDefinitionEvaluation, the private environment is set in step 13 and the ClassElementEvaluation is in step 25.

@nicolo-ribaudo Do you know if FF already had a tracking bug for this issue? I can't find one on Bugzilla.

from babel.

I'll ask today to a friend at Firefox, otherwise I'll open one.

Wdyt about creating a bugfix plugin for this, given that because of our decorators transform it might be common?

from babel.

class A {
  static #x = 42;
  static [class B {
    static {
      () => B.#x;
    }
  }];
}

There seems to be another difference here, this code throws in Firefox but not in Chrome.

from babel.

Wdyt about creating a bugfix plugin for this, given that because of our decorators transform it might be common?

Good idea, though I haven't figured out how to workaround this bug except transforming the whole class.

from babel.

Fun fact 😛 In Babel 7.21, compiling this code to es2015:

let capturedPrivateAccess;
class A {
  static #x = 42;
  static [(class {}, capturedPrivateAccess = () => A.#x)];
}
console.log(capturedPrivateAccess());

would then at runtime throw an error about A being in TDZ.

from babel.

Fun fact 😛 In Babel 7.21, compiling this code to es2015:

let capturedPrivateAccess;
class A {
  static #x = 42;
  static [(class {}, capturedPrivateAccess = () => A.#x)];
}
console.log(capturedPrivateAccess());

would then at runtime throw an error about A being in TDZ.

Yes, that is another bug, our current classTDZVisitor blindly forbids any class binding references in the computed key.

from babel.

It seems like wrapping the computed key in an IIFE works:

let capturedPrivateAccess;
class A {
  static #x = 42;
  static [(() => (class {}, capturedPrivateAccess = () => A.#x))()];
}
console.log(capturedPrivateAccess())

Great, and we will have to check whether it is an async/generator and emit other IIFEs likewise.

from babel.

SpiderMonkey just merged a fix for this, but let's still implement a workaround plugin for all the existing Firefox version. @JLHwung do you want to work on it since you are fixing other decorator bugs, or should I do it?

from babel.