-
Notifications
You must be signed in to change notification settings - Fork 664
Refactor MemberExpression AST structure #1799
Conversation
Test262 comparison coverage results on ubuntu-latest
|
Test262 comparison coverage results on windows-latest
Fixed tests (16):
|
let err = p | ||
.err_builder("optional chaining cannot contain private identifiers") | ||
.primary(range, ""); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This isn't true. err?.#test
works perfectly fine.
JsAnyReferenceMember = | ||
JsReferenceIdentifierMember | ||
| JsReferencePrivateMember | ||
|
||
// A reference to a member | ||
// a.b | ||
// ^ | ||
// let { b: c } = a | ||
// ^ | ||
JsReferenceIdentifierMember = | ||
name: 'ident' | ||
|
||
// A reference to a private member | ||
// a.#b | ||
// ^^ | ||
// let { #b: c } = a | ||
// ^^ | ||
JsReferencePrivateMember = | ||
'#' | ||
name: 'ident' | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not entirely sure about the naming here. Should these be postfixed with JsAnyReferenceMemberName
since these are names and not members? Might sound a bit weird in the case of JsReferenceIdentifierMemberName
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jamiebuilds wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know that I would call this a "reference" since it's not actually looking anything up in scope. Accessing a member uses completely different logic that could be affected by getters/proxies/etc, so relating it to scope references seems incorrect.
I like the idea of using JsStaticMember
(or JsLiteralMember
)
JsStaticMember(Name?) -- or -- JsLiteralMember(Name?)
JsPrivateMember(Name?)
- We could use the
*Name
suffix for all miscellaneous "identifier-like" nodes - We could use "literal" to mean "any value that can be determined from the source text alone" which would make "static" less overloaded since it's another language feature
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's an excellent point and something I haven't considered. My main crux is that the potential of name clashes.
- Classes and Object have
Js*ClassMember
andJs*ObjectMember
, and it might be a nice addition in the future to have aJsAnyMember
that is a union over all possible members. UsingJsStaticMember
andJsPrivateMember
would then not be part of that union which is confusing from a naming perspective - Classes and Object permit identifiers, string literals, and number literals as member names which are why this PR introduces a
JsLiteralMemberName
. The problem is, string literals and number literals are not permitted inMemberExpression's, which is why they need two different types (with different names, calling both
*LiteralMemberName` might be confusing if they are not interchangeable
That's why I opted for the Reference
prefix to distinguish the use cases clearly, but, as mentioned, I'm only somewhat happy with it.
An alternative that I considered is to prefix the member names used for classes and object expressions with Binding
because they introduce new bindings. That's probably more true for classes that have their own scope, and each member defines a new binding in that scope. Objects may define members, but they don't introduce a new binding to the scope (they bind the members on the object, but I don't think that's the meaning of Binding we're using).
Overall, my problem is that these names are similar but have different semantics nonetheless.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I talked about the naming with @jamiebuilds . We don't have a better name yet but we also came up with some more renames for other structures. So I think it's best to move on with this PR and fix the name when renaming all other fields/ nodes.
Deploying with Cloudflare Pages
|
bc542cc
to
3da3c66
Compare
3da3c66
to
3aff5af
Compare
Summary
Refactors the AST tree structure for MemberExpressions as part of #1725
BracketExpr
toJsComputedMemberExpression
DotExpr
toJsStaticMemberExpression
JsReferenceIdentifierMember
andJsReferencePrivateMember
which are references to member names (analog toJsReferenceIdentifierExpression
that references an identifier andJsBindingIdentifier
that defines an identifier)PrivatePropAccess
intoJsStaticMemberExpression
(enabled by introducingJsReferenceMember
SuperExpression
so thatsuper.test()
workssuper()
only works inside of constructor (I leave checking if we're inside of a subclass to another PR).SuperCall
as this can now be modelled usingCallExpr
Test Plan
Verified the coverage and that all tests are still passing. Added new integration tests.
The coverage is increasing because of the added check if
super
is called from inside a constructor.