Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Missing the AbortSignal.any() API.
This API is superficially simple, but required a number of deeper changes.
1 - The poor support for namespace/static functions introduced in #749 has been improved. Static functions, like
AbortSignal.timeout, are now correctly supported.I still think the
consolebehavior is weird, but it's now implemented as a receiver-less method (which is now supported for all methods). Possibly still not correct, but at least it's simpler and and better aligned with how we structure our code.2 - Like the
Windowbefore, this introduces an EventTarget which is not a libdom node, an AbortSignal. UnlikeWindow, this isn't a singleton and can't be easily detected. I corrupted the internal event type to serve as a discriminator to the event target. If this doesn't work for future cases, we'll have to come up with a more general solution, like attaching some internal_type_id to the event_target.3 - Ran into a variation of the empty-struct identity map issue (see: #812). This time I tried to solve this properly, but it turns out that making the identity map type-aware isn't without its challenges and drawback. Instead, I solved this specific by forcing unique addresses between conflicted objects. As punishment for my failure, I documented the issue: https://github.com/lightpanda-io/project/discussions/165
4 - I believe this is the first case where we've had to raise an arbitrary exception from Zig code (with a user-defined message). My solution exposes the underlying JS context (aka scope), which I don't like, but I don't expect this to be a common requirement, so if we need to change things around, it shouldn't be a problem.