Create InitialStencilAndDelazifications and associate it to ScriptSourceObject,
and store on-demand delazifications into the InitialStencilAndDelazifications.
InitialStencilAndDelazifications is merged into single CompilationStencil when
finishing, but the JS::Stencil-based API is going to be rewritten later not
to merge.
Differential Revision: https://phabricator.services.mozilla.com/D230378
We never reach `CompileFetchedModule` if we have an unknown module type since
we take the module type into account when we do mime type checking, so the file
always fails to load because of MIME mismatch, and we don't get the expected
`TypeError.` Checking if we have an unknown type should happen much earlier in
the process.
Differential Revision: https://phabricator.services.mozilla.com/D222222
This patch adds a module type parameter to
`ModuleLoaderBase::{CreateStaticImport,CreateDynamicImport},` and gets rid of a
bunch of hard-coded `JS::ModuleType::JavaScript.` However, the module type is
still hard-coded when we call `CreateDynamicImport` and `CreateStaticImport`.
Differential Revision: https://phabricator.services.mozilla.com/D218556
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
This patch adds a module type parameter to
`ModuleLoaderBase::{CreateStaticImport,CreateDynamicImport},` and gets rid of a
bunch of hard-coded `JS::ModuleType::JavaScript.` However, the module type is
still hard-coded when we call `CreateDynamicImport` and `CreateStaticImport`.
Differential Revision: https://phabricator.services.mozilla.com/D218556
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
We are looking into caching loaded script in memory. To do so we need something
to cache.
At the moment, the `ScriptLoadRequest` structure hold all the fields which are
loaded, and used before executing JavaScript code. Then, the `ScriptLoadRequest`
is not guaranteed to out-live the first execution.
Therefore, we have to move fields out of the `ScriptLoadRequest` such that they
can later be used by any caching mechanism. The `LoadedScript` is the closest
existing structure which exists which fit the description.
This patch moves fields out of the ScriptLoadRequest into the `LoadedScript`,
which already has a `LoadedScript` field.
The `LoadedScript` field is initialized sooner, when the `ScriptLoadRequest` is
created, to be subsituted later by a real cache implementation. At the moment
the function `ScriptLoadRequest::NoCacheEntryFound` is used as a placeholder to
change the state of the `ScriptLoadRequest` from `CheckingCache` to `Fetching`.
Existing initializations are replaced by assertions to fail in debug build if
the current patch does not reproduce the expected state properly.
The `LoadedScript` get fields such as the source text, the text length, the
bytecode buffer (which also contains SRI), and the offset at which the bytecode
starts within the bytecode buffer. As these fields are no longer reachable by
name, multiple accessors are added to work-around the issue. Using this as an
opportunity to add extra assertions as part of these accessors.
A new class named `LoadedScriptDelegate` is added to re-add, by inheritance, all
the accessors which used to be part of `ScriptLoadRequest` as methods which are
delegating to the field which is holding the `LoadedScript`. This class is using
templates to avoid virtual inheritance which might hinder inlining, especially
since `ScriptLoadRequest` cannot be made final, as `ModuleLoadRequest` extends
it.
The `ScriptFetchOptions` structure is moved to its own file to solve C++ include
issues.
Differential Revision: https://phabricator.services.mozilla.com/D163615
We are looking into caching loaded script in memory. To do so we need something
to cache.
At the moment, the `ScriptLoadRequest` structure hold all the fields which are
loaded, and used before executing JavaScript code. Then, the `ScriptLoadRequest`
is not guaranteed to out-live the first execution.
Therefore, we have to move fields out of the `ScriptLoadRequest` such that they
can later be used by any caching mechanism. The `LoadedScript` is the closest
existing structure which exists which fit the description.
This patch moves fields out of the ScriptLoadRequest into the `LoadedScript`,
which already has a `LoadedScript` field.
The `LoadedScript` field is initialized sooner, when the `ScriptLoadRequest` is
created, to be subsituted later by a real cache implementation. At the moment
the function `ScriptLoadRequest::NoCacheEntryFound` is used as a placeholder to
change the state of the `ScriptLoadRequest` from `CheckingCache` to `Fetching`.
Existing initializations are replaced by assertions to fail in debug build if
the current patch does not reproduce the expected state properly.
The `LoadedScript` get fields such as the source text, the text length, the
bytecode buffer (which also contains SRI), and the offset at which the bytecode
starts within the bytecode buffer. As these fields are no longer reachable by
name, multiple accessors are added to work-around the issue. Using this as an
opportunity to add extra assertions as part of these accessors.
A new class named `LoadedScriptDelegate` is added to re-add, by inheritance, all
the accessors which used to be part of `ScriptLoadRequest` as methods which are
delegating to the field which is holding the `LoadedScript`. This class is using
templates to avoid virtual inheritance which might hinder inlining, especially
since `ScriptLoadRequest` cannot be made final, as `ModuleLoadRequest` extends
it.
The `ScriptFetchOptions` structure is moved to its own file to solve C++ include
issues.
Differential Revision: https://phabricator.services.mozilla.com/D163615
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 reverts to the previous behaviour where inline module scripts with
dependencies would complete asynchronously. Previously this would have been
internal to the module loader base class.
Differential Revision: https://phabricator.services.mozilla.com/D192321
The request priority isn't propagated from `ScriptFetchOptions`, so
setting it has no effect for end-users. That will be implemented in a
following part.
Differential Revision: https://phabricator.services.mozilla.com/D183483
Based on the explanation on the bug, the solution would seem to be to call the
ModuleLoaderBase::OnModuleLoadComplete hook from a microtask. This causes a ton
of test failures.
Instead this patch changes the DOM script loader to implement this hook with a
runnable. This fixes the problem (verified manually) and all tests pass.
(Replacing the runnable with a microtask just in the DOM script loader also
does not work and results in many test failures. I'm still trying to understand
why.)
The changes to ContinueDynamicImport are removed because they are also on this
path and we don't need a microtask as well.
This takes us closer to the state before bug 1842798 landed when all the module
loader used MozPromise internally and completions like this happened via
runnables.
I was not able to immediately come up with a test for this.
Differential Revision: https://phabricator.services.mozilla.com/D185830
The request priority isn't propagated from `ScriptFetchOptions`, so
setting it has no effect for end-users. That will be implemented in a
following part.
Differential Revision: https://phabricator.services.mozilla.com/D183483
The request priority isn't propagated from `ScriptFetchOptions`, so
setting it has no effect for end-users. That will be implemented in a
following part.
Differential Revision: https://phabricator.services.mozilla.com/D183483
Stanca Serban