Might need constructor declaration too?

And also property declaration?

Constructors are just MethodDefinitions with the name constructor. I'll look into the property definition concern, as that may also have been missed by the class fields proposal.

Contains gets around this by shunting to ComputedPropertyContains for a ClassTail. It looks like this was missed in ContainsArguments, which would incorrectly look for arguments in a FieldDefinition's initializer. In general this isn't a problem because that would be a static error anyways, but it does mean that ContainsArguments incorrectly and unnecessarily recurs through nested FieldDefinition declarations:

class A {
  static B = class {
    static C = class {
      static D = arguments; //
    }
  }
}

In this case, ContainsArguments would descend all the way to D when checking the static semantics of A, B, and C, when only ContainsArguments for C really needs to do that descent. Instead, ContainsArguments should only check a ComputedPropertyName of the FieldDefinition. This seems to be a spec bug for class fields, which I can file shortly in the ecma262 repo.

@littledan, can you clarify for me why FieldInitializer is specified with ?Await? It seems like it should be ~Await:

While a class field's ComputedPropertyName could contain await in an Await context, an initializer can never be async since its wrapped in its own implicit function. Plus this doesn't make sense:

async function f(p) {
  return class C {
    x = await p; // when could this be awaited?
  };
}
let C = await f(Promise.resolve(1));
let obj = new C();
obj.x; // what is this value?

I've filed tc39/ecma262#2438 for the issue with ContainsArguments, and tc39/ecma262#2437 for the issue with FieldDefinition.

I've refactored ContainsAwait into two parts to better match Contains, adding a ComputedPropertyContainsAwait that mirrors ComputedPropertyContains. I've also updated ContainsAwait to more accurately mirror Contains except in the specific places where the algorithms must differ.