The tests are designed for this, and trying to accommodate 32-bit
platforms is difficult. Size concerns due to element packing and holes
are less of a problem on 32-bit platforms in any event.
move stylo_test build script guts from Python to Rust
stylo_test's build script is split between Python and Rust. style's
build script already has to perform complicated dances to determine an
appropriate binary to execute, depending on the platform. To avoid
copying and pasting that code, it seems reasonable to simply port the
Python code into Rust, thus making the relationship between generated
files and the cargo dependency output clearer. The new Rust is somewhat
more verbose, but not terribly so.
Doing this makes running `stylo_test` on Windows somewhat easier, as
we don't have to care about the particulars of Python executables. And
more Rust is more better.
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] There are tests for these changes
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/17925)
<!-- Reviewable:end -->
stylo_test's build script is split between Python and Rust. style's
build script already has to perform complicated dances to determine an
appropriate binary to execute, depending on the platform. To avoid
copying and pasting that code, it seems reasonable to simply port the
Python code into Rust, thus making the relationship between generated
files and the cargo dependency output clearer. The new Rust is somewhat
more verbose, but not terribly so.
`ElementStyles` holds an optional list of values for each eager pseudo-element.
However, the type was declared as a slice instead of a fixed size array, so an
extra 8 bytes were being allocated to hold the size, even though it never
changes.
Moving the constant size into the type reduces `ElementStyles` and `ElementData`
by 8 bytes.
MozReview-Commit-ID: GaO6DKFxUMo
Before this change, the `ComputedStyle` struct that is part of permanent style
data per element holds 2 `StrongRuleNode`s (unvisited and visited) and 2
`Arc<ComputedValues>` (unvisited and visited).
Both rule nodes and the visited values don't actually need to be here. This
patch moves these 3 to new temporary storage in `CascadeInputs` on
`CurrentElementInfo` during the match and cascade process. Rule nodes are
pushed down inside the `ComputedValues` for later access after the cascade.
(Visited values were already available there.)
The permanent style data per element now has just the `Arc<ComputedValues>` for
itself and eager pseudo-elements (plus the `RestyleHint`).
MozReview-Commit-ID: 3wq52ERMpdi
This enum type used to contain the result of parsing
one CSS source declaration (`name: value;`) and expanding shorthands.
Enum types are as big as the biggest of their variant (plus discriminant),
which was quite big because some shorthands
expand to many longhand properties.
This type was returned through many functions and methods,
wrapped and rewrapped in `Result` with different error types.
This presumably caused significant `memmove` traffic.
Instead, we now allocate an `ArrayVec` on the stack
and pass `&mut` references to it for various functions to push into it.
This type is also very big, but we never move it.
We still use an intermediate data structure because we sometimes decide
after shorthand expansion that a declaration is invalid after all
and that we’re gonna drop it.
Only later do we push to a `PropertyDeclarationBlock`,
with an entire `ArrayVec` or nothing.
In future work we can try to avoid a large stack-allocated array,
and instead writing directly to the heap allocation
of the `Vec` inside `PropertyDeclarationBlock`.
However this is tricky:
we need to preserve this "all or nothing" aspect
of parsing one source declaration,
and at the same time we want to make it as little error-prone as possible
for the various call sites.
`PropertyDeclarationBlock` curently does property deduplication
incrementally: as each `PropertyDeclaration` is pushed,
we check if an existing declaration of the same property exists
and if so overwrite it.
To get rid of the stack allocated array we’d need to somehow
deduplicate separately after pushing multiple `PropertyDeclaration`.
