Computed property names in class definitions can access the class definition during initialisation, this can be used to trigger an assertion in 9.2.11 SetFunctionName.
Maybe 14.5.15 ClassDefinitionEvaluation should perform the binding initialisation after step 18, so computed property names cannot access the not quite initialised class definition. Or 9.2.11 SetFunctionName need to handle non-extensible objects resp. 14.5.16 Runtime Semantics: Evaluation need to check the [[Extensible]] internal data slot before calling SetFunctionName.
Test case:
---
class X {
[(Object.preventExtensions(X), "")](){}
}
---
All callers of 9.2.11 SetFunctionName need to perform the [[Extensible]] check not only 14.5.16 Runtime Semantics: Evaluation.
Okay, once again: It's only 14.5.16 Runtime Semantics: Evaluation, not all callers of SetFunctionName. The other callers cannot gain access to the class definition during initialisation, because they all occur in anonymous function definition contexts.
fixed in rev23 editor's draft
moved binding initialization after step 18
fixed in rev23 draft