Clarify some code in do_create_interface_objects
rval.get() is believed to be always null upon entering this function.
This assumption is verified by the added assertion.
It makes more sense to move the block of code that was moved inside
the if statement which is the only place where it can be initialized.
Fixes#7941.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7943)
<!-- Reviewable:end -->
Implement Deref<Target=T> for JS<T> where T: Reflectable
We can only borrow `JS<T>` from rooted things, so it's safe to deref it.
The only types that provide mutable `JS<T>` things are `MutHeap<JS<T>>` and
`MutNullableHeap<JS<T>>`, which don't actually expose that they contain
`JS<T>` values.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8060)
<!-- Reviewable:end -->
We can only borrow JS<T> from rooted things, so it's safe to deref it.
The only types that provide mutable JS<T> things are MutHeap<JS<T>> and
MutNullableHeap<JS<T>>, which don't actually expose that they contain
JS<T> values.
added spec link for type mapping
Hi. added some of the spec links, that i could understand from the spec. Please mention if anything else needs to be added.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8031)
<!-- Reviewable:end -->
Fix uses of JS<T> as a type on the stack
`JS<T>` belongs on the heap, and only on the heap. This is a collection of fixes so that code uses either `Root<T>` or `&T` to pass around garbage-collected pointers.
Ideally, we could completely ban constructing a `JS<T>` outside of constructor functions, but we aren't quite there yet.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/8026)
<!-- Reviewable:end -->
get() must always return a rooted value, because we have no way of
ensuring the value won't be invalidated. set() takes an &T because it's
convenient; there isn't any need to expose JS<T>.
Introduce DOMClass::heap_size_of
It holds a function pointer to the HeapSizeOf::heap_size_of_children()
implementation corresponding to that IDL interface.
This removes the need for a clumsly TypeId-based match expression in the
former heap_size_of_eventtarget() function.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7972)
<!-- Reviewable:end -->
It holds a function pointer to the HeapSizeOf::heap_size_of_children()
implementation corresponding to that IDL interface.
This removes the need for a clumsly TypeId-based match expression in the
former heap_size_of_eventtarget() function.
rval.get() is believed to be always null upon entering this function.
This assumption is verified by the added assertion.
It makes more sense to move the block of code that was moved inside
the if statement which is the only place where it can be initialized.
Fixes#7941.
Don't generate useless InheritTypes interfaces
Interfaces with no descendant need neither a Base trait nor upcast functions, and interfaces with no ancestors neither a Derived trait nor downcast functions.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7735)
<!-- Reviewable:end -->
Interfaces with no descendant need neither a Base trait nor upcast functions,
and interfaces with no ancestors neither a Derived trait nor downcast functions.
Some interfaces like Node, CharacterData and HTMLTableCellElement are never
instantiated directly, only their descendant interfaces are. Those are marked
with [Abstract] to set their type_id to None instead of having dummy values
in the TypeId enums.
Combine script profiling with profile crates. Fixes#7514.
The script crate had its own built-in profiling which was basically doing the same thing as the profile crate. This wraps the internal profiling around the main profile functionality. Script-related tasks are now added to the ProfilerCategory enum.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7547)
<!-- Reviewable:end -->
After this pull request merged:
https://github.com/servo/servo/pull/7209
the 'script' component would never enter a 'built' state. In other
words, if one calls `mach build`, lets it complete, then calls `mach
build` again, the 'script' component would rebuild even though we
supposedly just built it. This was due to the `ParserResults.pkl`
getting placed in the `components/script` directory instead of the
output directory, causing cargo to think that there were unbuilt files.
