Skip to content
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

refactor(core): provide builtins as an Extension #10449

Merged
merged 2 commits into from
May 1, 2021

Conversation

AaronO
Copy link
Contributor

@AaronO AaronO commented Apr 30, 2021

Treats builtin ops (op_resources, op_close) and js (core.js, error.js) as a regular JsRuntime Extension that's always loaded (first, see the .insert(0 ...)

This guarantees that op_close, op_resources (and op_print with #10436) are ready to use after JsRuntime::new

Though builtins are special, they're not "that special", streamlining them will simplify things like moving JS src off heap generically for all extension provided JS without having to treat core.js, error.js as edge cases

Notes

  • Now that the builtin ops are registered by default, the first op registered by the user after JsRuntime::new will no longer have an OpId of 1 since those builtin ops will have taken those slots. I fixed the tests that relied on that assumption and in general it's strongly discouraged to rely on specific OpIds

Use core.opAsync() and op_names instead of opcall with a raw op_id

This broke, because now that we always load the builtin ops, the OpId==1 assumption was no longer true
Copy link
Member

@ry ry left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ry ry merged commit 578f2ba into denoland:main May 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants