* Add `no_trace` option to JSTraceable derive
* NoTrace wrapper
* Port some types to no_trace schematics
* Fixing my unsafe mistakes (not tracing traceables)
* Add docs & safety guards for no_trace
Safety guards (trait shenanigans) guarantees safety usage of `no_trace`
* Port canvas_traits to no_trace
* Port servo_media to no_trace
* Port net_traits to no_trace
* Port style to no_trace
* Port webgpu to no_trace
* Port script_traits to no_trace
* Port canvas_traits, devtools_traits, embedder_traits, profile_traits to no_trace
* unrooted_must_root lint in seperate file
* Add trace_in_no_trace_lint as script_plugin
* Composable types in must_not_have_traceable
* Introduced HashMapTracedValues wrapper
* `HashMap<NoTrace<K>,V>`->`HashMapTracedValues<K,V>`
* Port rest of servo's types to no_trace
* Port html5ever, euclid, mime and http to no_trace
* Port remaining externals to no_trace
* Port webxr and Arc<Mutex<_>>
* Fix spelling in notrace doc
This update pulls in improvements on mozjs that now removes the need to
pass pointers to CompileOptionsWraper::new(), allows NewProxyObject to
now accept a Singleton bool and JSClass and removes an unsafe
Handle::new usage.
Introduce dynamic module
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#25439
- [x] There are tests for these changes
Use `asynch` instead of `r#async`
<!-- Please describe your changes on the following line: -->
This is a vestige of the transition from 2015 to 2018 edition Rust.
`async` was added as a keyword in 2018 edition Rust, so `cargo fix`
changed the variable name here to `r#async`.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [ ] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
- [ ] These changes fix #___ (GitHub issue number if applicable)
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because this is just an internal name change
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Web developers can use `Dynamic Import` in a classic script; thus, we
need to save the script's private reference so that we can reuse it when
we're going to fetch a dynamic import module for a classic script.
Besides, because it's possible to use different executing context for a
dynamic import module (like `dynamic-import/string-compilation-other-document.html` WPT test),
we can't initialize a module owner at the timing of `SetScriptPrivate`;
thus, if the private module script doesn't hold an owner, we'll use a
DynamicImport owner for it.
This is a vestige of the transition from 2015 to 2018 edition Rust.
`async` was added as a keyword in 2018 edition Rust, so `cargo fix`
changed the variable name here to `r#async`.
Specifically, I changed the `text` field of `ScriptOrigin` from a
`DOMString` to an `Rc<DOMString>`. Then I updated all the related code
to work with an `Rc`.
This is just a first pass to get the code to compile. There are probably
more things I can do that will improve the code and further reduce
cloning.
In https://github.com/servo/servo/pull/26395/files#diff-3fe97584f564214ec8e7ebbf91747e03L253-R318,
we moved from `recursive checking` of dependency status to check only the
_current module_'s dependency status and its descendant dependency status and
also circular dependency status.
However, it will cause an issue.
For example, if the module dependency is like following
```
a -> b -> c -> d -> e
f -> g -> h -> c -> d -> e
```
In this example, if the d module is still under fetching but g is trying
to advance to finish. Then, it will cause a panic because module d is
g's grand-grand-grand-descendant which means it's still under fetching
and we can't instantiate module g.
Ideally, we should get rid of the checking in #26903 so, before #26903
fixed, we can just move back to the recursive checking way which will
ensure all descendants are not fetching.
In the previous Promise.all way, we registered a promise for every
module script which means we will need to do many complex checkings like
"is this top level?" and it will make us much more difficult to understand
how the module script algorithm works.
In the new manual checking way, we will only register promises for top
level modules to notify its owner (e.g. the script element) to finish
the load. So, we can understand it much more easily and would be more
spec-aligned.
Also, I think the `Ready` and `FetchFailed` status are quite confusing
and we actually don't need them so they're removed in this patch. Then,
we will always go to `Finished` instead.
It would basically be following steps:
+-----------------+
| Failed to fetch | ----------+
+--------------+ +----------+ / +-----------------+ |
| Fetch module | ----> | Fetching | ---+ v
+--------------+ +----------+ \ +---------+ +---------------------+
| Fetched | | Advance to Finished |
+---------+ +---------------------+
| ^
v |
+-------------------+ |
| Fetch descendants | ----- if no descendants
+-------------------+
|
V
+----------------------+
| Fetching Descendants |
+----------------------+
In `Advance to Finished`, it means that module script is about to finished so it will
1. Notify all of its `ready` and `not finished` parents to finish
2. Link (instantiate) the module
3. Resolve its promise to notify owner(s) to finish
Return the highest priority error from the descendant instead of return the very first one
The test failed because we didn't return the highest priority error (which is network error in this case).
As Manish mentioned in https://github.com/servo/servo/issues/25436#issuecomment-571065323, that's because we're using the Promise.all trick to signal loads.
If we can avoid relying on Promise.all, maybe we don't need to do a complex logic like this; instead, ideally, we should always finish the module load immediately when we hit network failure so that we don't even need to do the `max()` comparison.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#25436
- [x] There are tests for these changes
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
