Since the module graph is now traversed within the JS engine itself, the
related data structures in the host layer are no longer necessary.
Differential Revision: https://phabricator.services.mozilla.com/D255129
This patch adds the new parameter to the `NewVisitedSetForTopLevelImport`
method, but we hard-code the module type (which will be addressed in a later
patch)
Differential Revision: https://phabricator.services.mozilla.com/D218555
This patch gets rid of most hard-coded `JS::ModuleType::JavaScript` in
`js/loader/ModuleLoaderBase.cpp`. However, the module type is still hard-coded
when constructing the `ModuleLoadRequest` (will be addressed in a later patch).
Differential Revision: https://phabricator.services.mozilla.com/D218554
The module maps (`mFetchingModules` and `mFetchedModules`) in
`ModuleLoaderBase`, and `VisitedURLSet` were previously only keyed by the URL
and used the `nsURIHashKey` hashtable key class. This is no longer sufficient,
and the key should also contain the module type.
This patch introduces a new hashtable key class called `ModuleMapKey` and
changes `mFetchingModules`, `mFetchedModules`, and `VisitedURLSet` to use the
new key type.
To make this a bit easier to review, this first patch only introduces the new
key type and hard-codes the type to Javascript, where the key is constructed.
The hard-corded module types will be fixed in later patches.
Differential Revision: https://phabricator.services.mozilla.com/D155160
This patch adds the new parameter to the `NewVisitedSetForTopLevelImport`
method, but we hard-code the module type (which will be addressed in a later
patch)
Differential Revision: https://phabricator.services.mozilla.com/D218555
This patch gets rid of most hard-coded `JS::ModuleType::JavaScript` in
`js/loader/ModuleLoaderBase.cpp`. However, the module type is still hard-coded
when constructing the `ModuleLoadRequest` (will be addressed in a later patch).
Differential Revision: https://phabricator.services.mozilla.com/D218554
The module maps (`mFetchingModules` and `mFetchedModules`) in
`ModuleLoaderBase`, and `VisitedURLSet` were previously only keyed by the URL
and used the `nsURIHashKey` hashtable key class. This is no longer sufficient,
and the key should also contain the module type.
This patch introduces a new hashtable key class called `ModuleMapKey` and
changes `mFetchingModules`, `mFetchedModules`, and `VisitedURLSet` to use the
new key type.
To make this a bit easier to review, this first patch only introduces the new
key type and hard-codes the type to Javascript, where the key is constructed.
The hard-corded module types will be fixed in later patches.
Differential Revision: https://phabricator.services.mozilla.com/D155160
In the following module graph:
0.html
+---- 1.mjs
+---- non_existing.mjs
+---- 3.mjs
+----- 2.mjs
+---- 3.mjs
Both 1.mjs and 2.mjs have a common submodule called 3.mjs
But 1.mjs also has a non-existing submodule, so we can't instantiate the
module graph of 1.mjs. which in turn will cancel 3.mjs
But 3.mjs is also a sub-module of 2.mjs, so in order to instantiate the
module graph of 2.mjs, we skip canceling 3.mjs when we processed 1.mjs
Differential Revision: https://phabricator.services.mozilla.com/D209210
The initial problem reported in the bug is that we try to speculatively load a
bareword import before the import map is dynamically inserted that makes that
load valid. The load fails and then we cache the failure in the module map.
The more general problem is that import maps change the locations that imports
are resolved to so if when there is a dynamically inserted import map
speculative preload may load and cache the wrong things.
This patch fixes this problem by removing any preloaded modules from the module
map when an import map is registered.
Previously we used to do something like this but it was changed because I
wasn't confident that it wouldn't remove too much. However it appears that this
is necessary to handle this situation, so it's implemented here but with more
checks that it only removes preloaded modules. This is handled by adding extra
flags where necessary so we have the information on hand to check.
I've made these diagnostic asserts so that this actually gets check in real use.
Differential Revision: https://phabricator.services.mozilla.com/D202611
The initial problem reported in the bug is that we try to speculatively load a
bareword import before the import map is dynamically inserted that makes that
load valid. The load fails and then we cache the failure in the module map.
The more general problem is that import maps change the locations that imports
are resolved to so if when there is a dynamically inserted import map
speculative preload may load and cache the wrong things.
This patch fixes this problem by removing any preloaded modules from the module
map when an import map is registered.
Previously we used to do something like this but it was changed because I
wasn't confident that it wouldn't remove too much. However it appears that this
is necessary to handle this situation, so it's implemented here but with more
checks that it only removes preloaded modules. This is handled by adding extra
flags where necessary so we have the information on hand to check.
I've made these diagnostic asserts so that this actually gets check in real use.
Differential Revision: https://phabricator.services.mozilla.com/D202611
The initial problem reported in the bug is that we try to speculatively load a
bareword import before the import map is dynamically inserted that makes that
load valid. The load fails and then we cache the failure in the module map.
The more general problem is that import maps change the locations that imports
are resolved to so if when there is a dynamically inserted import map
speculative preload may load and cache the wrong things.
This patch fixes this problem by removing any preloaded modules from the module
map when an import map is registered.
Previously we used to do something like this but it was changed because I
wasn't confident that it wouldn't remove too much. However it appears that this
is necessary to handle this situation, so it's implemented here but with more
checks that it only removes preloaded modules. This is handled by adding extra
flags where necessary so we have the information on hand to check.
I've made these diagnostic asserts so that this actually gets check in real use.
Differential Revision: https://phabricator.services.mozilla.com/D202611
In Gecko we use a LoadedScript pointer as the referencing private for dynamic
imports. This is passed through the JS engine as a private value, which doesn't
care what it means. Currently we store this in the module loader as a JS::Value,
but we could just as well unpack it since we know what it is. That lets use a
RefPtr which also keeps it alive and will let use remove some manual reference
counting.
We also don't need to pass it to the CreateDynamicImport method twice.
This change makes it the responsibility of the module loader for keeping the
referencing private alive until FinishDynamicModuleImport is called.
Differential Revision: https://phabricator.services.mozilla.com/D196974
This replaces the use of a promise to wait for all imports of a module to load
with a counter of reminaing imports in the parent and a pointer to the parent
that is waiting in the child. The parent request is updated immediately rather
than by dispatching a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183273
This replaces the use of a promise to wait for all imports of a module to load
with a counter of reminaing imports in the parent and a pointer to the parent
that is waiting in the child. The parent request is updated immediately rather
than by dispatching a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183273
This replaces the use of a promise to wait for all imports of a module to load
with a counter of reminaing imports in the parent and a pointer to the parent
that is waiting in the child. The parent request is updated immediately rather
than by dispatching a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183273
This replaces the use of a promise to wait for all imports of a module to load
with a counter of reminaing imports in the parent and a pointer to the parent
that is waiting in the child. The parent request is updated immediately rather
than by dispatching a runnable.
Differential Revision: https://phabricator.services.mozilla.com/D183273
We should check for previous cancellation on all path where a module load
request's state can be changed by an asynchronous action. Also add assertions
about the expected previous state where possible.
Differential Revision: https://phabricator.services.mozilla.com/D168233
This removes the global object field from the script load context and gets the
global from the script loader / module loader where necessary.
Differential Revision: https://phabricator.services.mozilla.com/D142833
The script loader will need to deal with requests from more than one module
loader so this adds methods to the request which dispatch to the correct
loader.
Differential Revision: https://phabricator.services.mozilla.com/D142828
Yoshi Cheng-Hao Huang