-
-
Notifications
You must be signed in to change notification settings - Fork 411
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
[Merged by Bors] - Refactor some class features #2513
Conversation
Test262 conformance changes
Fixed tests (265):
|
Codecov Report
@@ Coverage Diff @@
## main #2513 +/- ##
==========================================
+ Coverage 50.38% 50.98% +0.59%
==========================================
Files 377 373 -4
Lines 36917 36812 -105
==========================================
+ Hits 18600 18767 +167
+ Misses 18317 18045 -272
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
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.
Really impressive work! I have some questions about our spec compliance though.
boa_engine/src/object/mod.rs
Outdated
@@ -1773,58 +1772,119 @@ impl Object { | |||
self.properties.remove(key) | |||
} | |||
|
|||
/// Check if a private name exists. |
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 seeing this resembles the PrivateElementFind operation and friends. Could this be moved to boa_engine/src/object/operations.rs
and adapted to somewhat resemble the spec operations? Probably also initialize_instance_elements
.
I say this because there's a host hook HostEnsureCanAddPrivateElement that needs to be called on the PrivateFieldAdd and PrivateMethodOrAccessorAdd operations to restrict the addition of new private fields for an object.
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.
Good call. I've refactored those methods and they are mostly equivalent to the spec now.
description: Sym, | ||
|
||
/// The indices of the private name are included to ensure that private names are unique. | ||
pub(crate) indices: (usize, usize), |
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 was reading the spec about private names and it specifies that PrivateName
s should be globally unique, but indices
are only unique in the context of a single Context
, right? I was thinking that the global uniqueness property is probably to restrict the access of private names from objects that share the same indices
but don't belong to the same Context
, but to me it seems like this doesn't prevent that? I ask this because I don't know if you've already considered 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.
There is still some uniqueness missing with this implementation. We indeed have to add some runtime unique identifier to separate PrivateName
of multiple objects that are created from the same class. I think this will probably be some kind of Context
wide index. As far as different Context
s go, I think that would need some further work as our Context
is currently also a Realm
. If we have figured out how we can separate those, the Context
should be the outermost api to the engine and imo should the the uniqueness-border.
I left the runtime uniqueness out of the PR to limit the scope somewhat.
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.
It's okay! Can you add a TODO
describing this then? It would be good to track this for when we implement proper Realms.
7f922eb
to
bd01017
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.
Everything looks good! Just some small nitpicks.
Also, thanks for adding the host_ensure_can_add_private_element
! It'll make it easier to replace when the hooks API merges.
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.
Nice job!
bd24008
to
85abc6e
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.
Looks good!
bors r+ |
This Pull Request fixes various bugs related to classes. The biggest changes are: - Changed private names to be unique across multiple classes. - Changed private name resolution to work via a visitor after a class is parsed. The way class early errors are defined makes it impossible to perform private name resolution while parsing. - Added function names to class methods. - Added class name binding to method function environments. - Separated opcodes for `static` and non-`static` class method definitions to make the above operations possible. There are still some bugs and further issues with classes but this is already a lot.
Pull request successfully merged into main. Build succeeded: |
This Pull Request fixes various bugs related to classes.
The biggest changes are:
static
and non-static
class method definitions to make the above operations possible.There are still some bugs and further issues with classes but this is already a lot.