* 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
[rust-lang/rust#95562][1] renames the existing method `get_attrs` to
`get_attrs_unchecked` and introduces a new method in its former place.
The new method takes an attribute name and returns attributes of that
name. It also checks that, if the attribute name is marked as local-
only, the given `DefId` is local as well to prevent misuses. The old
method, now named `get_attrs_unchecked`, returns all attributes of a
given `DefId`; thus it's "unchecked" in the sense that it's up to the
callers to be certain whether the attributes they are looking for are
local-only.
The new `get_attrs` method lacks the support for attribute names with
more than one path component, which is why we can't just migrate to the
new `get_attrs` method here. Although `get_attrs_unchecked` is marked
for future removal in the compile source code, there's a discussion
about [supporting][2] this use case.
[1]: https://github.com/rust-lang/rust/pull/95562
[2]: https://github.com/rust-lang/rust/pull/95562/files#r915537557
The nightly-2021-03-12 toolchain doesn't have RLS on Windows. This
breaks code completion in Visual Studio Code because the rust plugin
picks up the project toolchain.
RLS is available in all tier one platforms in nightly-2021-05-18 per:
https://rust-lang.github.io/rustup-components-history/
Signed-off-by: Dominic Cooney <dominic.cooney@gmail.com>
At first I was considering moving it to a procedural macro
(source-level information should be sufficient),
and started by trying to reproduce the error case
by changing `htmldivelement.rs` to use `Element` instead of `HTMLElement`
as the first field.
The output was:
```rust
error[E0308]: mismatched types
--> /home/simon/servo2/target/debug/build/script-4caa244faca7d10f/out/Bindings/HTMLDivElementBinding.rs:665:31
|
665 | let _: &HTMLElement = self.as_parent();
| ^^^^^^^^^^^^^^^^ expected struct `dom::htmlelement::HTMLElement`, found struct `dom::element::Element`
|
= note: expected type `&dom::htmlelement::HTMLElement`
found type `&dom::element::Element`
```
This line number is inside a generated method called `__assert_parent_type`.
As far as I can tell, any case where this lint would error is already caught
by such methods. The lint is therefore redundant and can safely be removed.
