New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add private-property-in-object support #11372
Add private-property-in-object support #11372
Conversation
/cc @ljharb |
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.
LGTM overall
return; | ||
} | ||
|
||
path.replaceWith(template.expression.ast`${id}.has(${right})`); |
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.
just curious; do these field WeakMaps have WeakMap.prototype.has
copied onto them? or can i intercept babel private fields, even in spec mode, by replacing WeakMap.prototype.has
?
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.
We do not secure the weak
maps, so this will do a prototype reference. Note that even get
and set
calls go through the prototype, too. We can't ensure the order of our evaluation, so the WeakMap
could have already been patched by the time we reach the class definition.
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.
Of course - you can't protect against first-run code, but to be spec compliant you'd have to at least protect against later code. Object.defineProperties(id, Object.getOwnPropertyDescriptors(WeakMap.prototype))
at id
creation would address that.
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.
Currently, all of our output assumes that builtins haven't been modified.
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.
oof, ok - it's totally fine to assume they haven't been modified at module evaluation time (you don't really have a choice) but it's not fine to assume they haven't been modified later. that should be fixed asap (but not in this PR, obviously)
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.
- We should also throw when private in is out of the class scope.
({
test() {
#x in {};
}
})
#constructor
as private identifier is a syntax error when it is used in a class element. Should we also forbid#constructor in c
? @ljharb
@JLHwung I would assume |
I think that for |
...l-parser/test/fixtures/experimental/class-private-methods/asi-failure-generator/options.json
Outdated
Show resolved
Hide resolved
I've just added an early error for |
75e7c6f
to
47dbbfd
Compare
@@ -1158,7 +1171,11 @@ export default class ExpressionParser extends LValParser { | |||
const isPrivate = this.match(tt.hash); | |||
|
|||
if (isPrivate) { | |||
this.expectOnePlugin(["classPrivateProperties", "classPrivateMethods"]); |
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 think throwing missing privateIn
error for the common private property case will confuse users.
class C {
#p = 42;
}
Instead we can expect privateIn
when we see tt._in
after a private name.
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 understand the suggestion. I need to expect one of the 3 plugins here, or else I won't be able to parse the private name.
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 just realize that this line is never failed due to https://github.com/babel/babel/pull/11478/files#diff-80da704a8d2fc8d339ab57f154fb225eL429, which I address in #11478.
Base on #11478 and current implementation, if users are enabling classPrivateProperties
but without privateIn
, the following case does not throw missing privateIn
error. (REPL)
class C {
#p = 42;
m() { return #p in this }
}
because we never really check privateIn
as long as classPrivateProperties
is enabled.
Can you add a test case to packages/babel-parser/test/fixtures/experimental/_no-plugin
?
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.
We check at https://github.com/babel/babel/pull/11372/files#diff-56fea09eea2de51b8291db400d2f69beR1142. Added a test, we get SyntaxError: Unexpected token
at the #
in #foo in {}
.
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.
Can we throw the privateIn plugin is expected
when we see #foo in {}
but privateIn
is missing? Just like we did for classPrivateProperties
.
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.
There are several conflicting desires here:
- Parsing smart pipelines, and giving good errors
- Parsing invalid
#foo
expressions (not followed byin
) - Parsing
#foo in {}
expressions, but not having plugin enabled
I don't have a good solution to all three of these. If you can push a commit, that'd be awesome.
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.
Pushed a commit that should address 2) and 3).
For 1) we are printing good errors when |>
is seen but no pipeline
plugin. I think current situation is acceptable and since they are competing proposals we can give better errors after any of them advances.
47dbbfd
to
dc6872d
Compare
Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/21980/ |
f424252
to
3b282c4
Compare
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit f304cdb:
|
3b282c4
to
5103f89
Compare
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.
Thanks @JLHwung for helping!
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.
Thanks.
Excellent, thanks for the help! |
@jridgewell Could you add a docs page for this new plugin to |
Co-Authored-By: Nicolò Ribaudo <nicolo.ribaudo@gmail.com>
cdc5654
to
a19930f
Compare
Note: this is not merged to |
https://github.com/tc39/proposal-private-fields-in-in Co-Authored-By: Nicolò Ribaudo <nicolo.ribaudo@gmail.com> Co-Authored-By: Huáng Jùnliàng <jlhwung@gmail.com>
https://github.com/tc39/proposal-private-fields-in-in Co-Authored-By: Nicolò Ribaudo <nicolo.ribaudo@gmail.com> Co-Authored-By: Huáng Jùnliàng <jlhwung@gmail.com>
https://github.com/tc39/proposal-private-fields-in-in
The parsing is a little loose, but it's going to take a lot of effort to restrict it to only
in
binary expressions.