You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Contains gets around this by shunting to ComputedPropertyContains for a ClassTail. It looks like this was missed in ContainsArguments, which will 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:
classA{staticB=class{staticC=class{staticD=arguments;// static error, but for `A`}}}
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. In the case where there's a static error, per the spec it would be incorrectly attributed to A and not C above.
If there's no static error, then ContainsArguments needlessly descends though the AST when it encounters the Initializer of a FieldDefinition:
classA{staticB=class{staticC=class{staticD=0;}}}
In this case, ContainsArguments descends all the way to D for A, B, and C, which would be a waste of processing time in a literal interpretation of the specification.
I suggest that ContainsArguments be amended to include this rule:
FieldDefinition : ClassElementName Initializer?
Return ContainsArguments of ClassElementName.
The text was updated successfully, but these errors were encountered:
Contains
gets around this by shunting toComputedPropertyContains
for a ClassTail. It looks like this was missed inContainsArguments
, which will incorrectly look forarguments
in a FieldDefinition's initializer. In general this isn't a problem because that would be a static error anyways, but it does mean thatContainsArguments
incorrectly and unnecessarily recurs through nested FieldDefinition declarations:In this case,
ContainsArguments
would descend all the way toD
when checking the static semantics ofA
,B
, andC
, when onlyContainsArguments
forC
really needs to do that descent. Instead,ContainsArguments
should only check a ComputedPropertyName of the FieldDefinition. In the case where there's a static error, per the spec it would be incorrectly attributed toA
and notC
above.If there's no static error, then
ContainsArguments
needlessly descends though the AST when it encounters the Initializer of a FieldDefinition:In this case,
ContainsArguments
descends all the way toD
forA
,B
, andC
, which would be a waste of processing time in a literal interpretation of the specification.I suggest that
ContainsArguments
be amended to include this rule:The text was updated successfully, but these errors were encountered: