Refactor and tidy up the modules implementation following the loader refactoring
Categories
(Core :: JavaScript Engine, task, P1)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox143 | --- | fixed |
People
(Reporter: jonco, Assigned: jonco)
References
(Blocks 1 open bug)
Details
Attachments
(12 files)
|
Bug 1980126 - Part 1: Make LoadModuleResolved/RejectedCallbacks into function pointers r?allstarschh
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
Following on from landing the module loader (spec) refactor in bug 1820594, there are a bunch of things we can do to tidy up the code.
| Assignee | ||
Comment 1•1 year ago
|
||
We usually use function pointers for callbacks into the JS engine.
These are simpler to deal with and also std::function can alocate memory in
some situations which is undesirable.
The patch converts these to function pointers and also refactors
ModuleLoaderBase.cpp where these are defined for the main module loader.
| Assignee | ||
Comment 2•1 year ago
|
||
The finalizer for this only frees memory so it doesn't have to be foreground finalized.
The rest of the patch simplifies object creation a little.
| Assignee | ||
Comment 3•1 year ago
|
||
This moves the code that deal with dynamic import from
builting/ModuleObject.cpp to vm/Modules.cpp to be with the rest of the modules
implementation where it belongs.
| Assignee | ||
Comment 4•1 year ago
|
||
This merges the two versions of FinishLoadingImportedModule so there's a single
API that takes a payload rather than separate ones for promise/statePrivate.
| Assignee | ||
Comment 5•1 year ago
|
||
Similar to the previous patch, this makes the FinishLoadingImportedModuleFailed and
FinishLoadingImportedModuleFailedWithPendingException APIs take a single
payload argument.
| Assignee | ||
Comment 6•1 year ago
|
||
We use ScopeExit here to ensure we call FinishLoadingImportedModuleFailed on
error. However sometimes we call this directly and then exit without releasing
the guard and so call it again.
The patch cleans this up and makes the guard report the pending exception if
set but still report an exception otherwise. (In future we might think about
insisting that an exception is set if we leave early.)
| Assignee | ||
Comment 7•1 year ago
|
||
This makes it so FinishLoadingImportedModuleFailedWithPendingException gets the
current exception and calls FinishLoadingImportedModuleFailed.
| Assignee | ||
Comment 8•1 year ago
|
||
This moves some steps related to updating referrer.loadedModules from the
statePrivate path into the common path also used for dynamic imports.
There's still a slight spec difference because we only support module referrers
in our implementation and not script or realm referrers. However we don't ever
use loadedModules for anything except assertions for those referrer kinds.
| Assignee | ||
Comment 9•1 year ago
|
||
Following the previous patch a bunch of tests started passing. This also
updates a few tests that as far as I can tell were always passing evening
though they were marked as possibly failing.
| Assignee | ||
Comment 10•1 year ago
|
||
Previously this passed separate statePrivate and promise arguments, only one of
which was used at a time.
| Assignee | ||
Comment 11•1 year ago
|
||
The moduleRequest field of DynamicImportContextObject is never used for
anything so can be removed.
I added some spec steps around this code too.
| Assignee | ||
Comment 12•1 year ago
|
||
Comment 13•1 year ago
|
||
Comment 14•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/7cc93a61dcf9
https://hg.mozilla.org/mozilla-central/rev/dc050749ef8c
https://hg.mozilla.org/mozilla-central/rev/82da124b774a
https://hg.mozilla.org/mozilla-central/rev/a88003d84e39
https://hg.mozilla.org/mozilla-central/rev/e87aae5e5702
https://hg.mozilla.org/mozilla-central/rev/e8f85784d986
https://hg.mozilla.org/mozilla-central/rev/55b4afc09f65
https://hg.mozilla.org/mozilla-central/rev/5648b19b8155
https://hg.mozilla.org/mozilla-central/rev/b710df1831e1
https://hg.mozilla.org/mozilla-central/rev/ab86f64d7537
https://hg.mozilla.org/mozilla-central/rev/205405c7409c
https://hg.mozilla.org/mozilla-central/rev/97c1e6d6cbd7
https://hg.mozilla.org/mozilla-central/rev/a608780329b8
Comment 15•1 year ago
|
||
Comment 16•1 year ago
|
||
Backed out for causing wpt failures on before-prepare-iframe-success-external-module.html
Comment 17•1 year ago
|
||
| Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Comment 19•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/833105cacc8d
https://hg.mozilla.org/mozilla-central/rev/1aa8baaa297f
https://hg.mozilla.org/mozilla-central/rev/195d7b536123
https://hg.mozilla.org/mozilla-central/rev/8ef0f18dddeb
https://hg.mozilla.org/mozilla-central/rev/5e152ff1e0c5
https://hg.mozilla.org/mozilla-central/rev/284683a40c99
https://hg.mozilla.org/mozilla-central/rev/b770eb79da82
https://hg.mozilla.org/mozilla-central/rev/a94d628f4895
https://hg.mozilla.org/mozilla-central/rev/686dd16d5066
https://hg.mozilla.org/mozilla-central/rev/aa9be607dad3
https://hg.mozilla.org/mozilla-central/rev/9cc36384db92
https://hg.mozilla.org/mozilla-central/rev/4aae58151731
https://hg.mozilla.org/mozilla-central/rev/1ec8400efa8a
Updated•1 year ago
|
Description
•