The only fishy bit is the animation stuff. In particular, there are two places
where we just mint the revert behavior:
* When serializing web-animations keyframes (the custom properties stuff in
declaration_block.rs). That codepath is already not sound and I wanted to
get rid of it in bug 1501530, but what do I know.
* When getting an animation value from a property declaration. At that point
we no longer have the CSS rules that apply to the element to compute the
right revert value handy. It'd also use the wrong style anyway, I think,
given the way StyleBuilder::for_animation works.
We _could_ probably get them out of somewhere, but it seems like a whole lot
of code reinventing the wheel which is probably not useful, and that Blink
and WebKit just cannot implement either since they don't have a rule tree,
so it just doesn't seem worth the churn.
The custom properties code looks a bit different in order to minimize hash
lookups in the common case. FWIW, `revert` for custom properties doesn't seem
very useful either, but oh well.
Differential Revision: https://phabricator.services.mozilla.com/D21877
Once we've parsed the variable references, there is no need to keep an entire HashSet
object around, as all we do is iterate over the values.
Differential Revision: https://phabricator.services.mozilla.com/D11735
It's a bit useless to keep a set of invalid properties if we're going
to use them just to reject lookups into another key. This makes it more
consistent with the cascade / no-references code, and should not change
behavior.
Differential Revision: https://phabricator.services.mozilla.com/D9632
I think it used to be the case that all PropertyDeclaration variants had a
DeclaredValueOwned<T> inside. But that's no longer the case, so this abstraction
seems less useful now.
Differential Revision: https://phabricator.services.mozilla.com/D5978
This more concrete wrapper type can write a prefix the very first time something
is written to it. This allows removing plenty of useless monomorphisations caused
by the former W/SequenceWriter<W> pair of types.
Servo currently uses `heapsize`, but Stylo/Gecko use `malloc_size_of`.
`malloc_size_of` is better -- it handles various cases that `heapsize` does not
-- so this patch changes Servo to use `malloc_size_of`.
This patch makes the following changes to the `malloc_size_of` crate.
- Adds `MallocSizeOf` trait implementations for numerous types, some built-in
(e.g. `VecDeque`), some external and Servo-only (e.g. `string_cache`).
- Makes `enclosing_size_of_op` optional, because vanilla jemalloc doesn't
support that operation.
- For `HashSet`/`HashMap`, falls back to a computed estimate when
`enclosing_size_of_op` isn't available.
- Adds an extern "C" `malloc_size_of` function that does the actual heap
measurement; this is based on the same functions from the `heapsize` crate.
This patch makes the following changes elsewhere.
- Converts all the uses of `heapsize` to instead use `malloc_size_of`.
- Disables the "heapsize"/"heap_size" feature for the external crates that
provide it.
- Removes the `HeapSizeOf` implementation from `hashglobe`.
- Adds `ignore` annotations to a few `Rc`/`Arc`, because `malloc_size_of`
doesn't derive those types, unlike `heapsize`.
Fixes warnings from rust-lang/rust#44229 when `--enable-commonmark` is
passed to rustdoc.
This is mostly a global find-and-replace for bare URIs on lines by
themselves in doc comments.
After #18791, this is the major custom_properties perf bottleneck in the
testcase from bug 1405411.
I'm looking into how to efficiently merge this into `substitute_all`, but
meanwhile this is worth landing, and makes most of the overhead go away.
MozReview-Commit-ID: LMUGc8kPhhE
I'm about to introduce more state here to implement optimizations for custom
property cascading, so this abstraction is useful to encapsulate that state.
In custom_properties::SpecifiedValue::parse.
It's not a big deal now, but it's useful to simplify testing this stuff, since
it avoids forcing us to mock it.
In #18745, I replaced a few manual iterations over `index` with the iterator,
and it changed the behavior of `layout/style/test/test_variables_order.html`,
since it turns out that the iterator iterates right to left.
I think this is just an accident that happened due to inconsistencies in how we
were iterating over it, and that our behavior was inconsistent (since we
iterated rtl in some cases, but ltr in others seems like it'd be inconsistent
depending on the depth of the tree and different stuff).
This brings back the expected behavior again, and ensures we iterate over a
consistent order every time.
