No behavior change, just cleanup. Actually seem this technically _adds_ some code even
though it's a cleanup, but that's mostly because of the wrapping of the
derive list. The resulting code is simpler (more in-line with our usual
things, so I think it's an improvement).
Differential Revision: https://phabricator.services.mozilla.com/D111551
This reduces the amount of assembly instructions generated by this
function from 18k+ to ~800.
This should make reasoning about its stack space usage sane, and should
fix the ASAN stack overflows, but also we should take this regardless,
because it's saner and makes reading it simpler.
I also think that the writing_mode shenanigans is fixing a bug (I think
before this, we'd pick the first physical value which mapped to any of
the properties, which is wrong), but I haven't bothered looking for a
test-case that fails before my patch. The relevant WPTs
(css/css-logical/animation*) still pass.
Differential Revision: https://phabricator.services.mozilla.com/D105342
It's only used to disambiguate between the one-argument and the trait
version of Keyword::parse. Instead, just explicitly use the trait
version, so that we don't need to specify it.
Differential Revision: https://phabricator.services.mozilla.com/D104328
This does not (yet) upgrade ./rust-toolchain
The warnings:
* dead_code "field is never read"
* redundant_semicolons "unnecessary trailing semicolon"
* non_fmt_panic "panic message is not a string literal, this is no longer accepted in Rust 2021"
* unstable_name_collisions "a method with this name may be added to the standard library in the future"
* legacy_derive_helpers "derive helper attribute is used before it is introduced" https://github.com/rust-lang/rust/issues/79202
This is just a refactor in the right direction. Eventual goal is:
* All inherited properties use ArcSlice<>.
* All reset properties use OwnedSlice<> (or ThinVec<>).
No conversion happens at all, so we can remove all that glue, and also
compute_iter and co.
Of course there's work to do, but this is a step towards that.
Differential Revision: https://phabricator.services.mozilla.com/D30127
It's not very easy to understand on its current state, and it causes subtle bugs
like bug 1533654.
It could be simpler if we centralized where the interactions between properties
are handled. This patch does this.
This patch also changes how MathML script sizes are tracked when scriptlevel
changes and they have relative fonts in between.
With this patch, any explicitly specified font-size is treated the same (being a
scriptlevel boundary), regardless of whether it's either an absolute size, a
relative size, or a wide keyword.
Relative lengths always resolve relative to the constrained size, which allows
us to avoid the double font-size computation, and not give up on sanity with
keyword font-sizes.
I think given no other browser supports scriptlevel it seems like the right
trade-off.
Differential Revision: https://phabricator.services.mozilla.com/D23070
The way the copy-on-write stuff works, and the way that we have to apply
properties from most specific to less specific guarantees that always that we're
going to inherit an inherited property, or reset a reset property, we have
already the right value on the style.
Revert relies on that, so there doesn't seem to be a reason to not use that fact
more often and skip useless work earlier.
Font-size is still special of course... I think I have a way to move the
specialness outside of the style, but piece by piece.
Differential Revision: https://phabricator.services.mozilla.com/D21882
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
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
System font keywords are not a valid value for those properties.
The newly-added #[css(skip)] would be reused by deriving algorithm of
SpecifiedValueInfo to skip them as well.
Bug: 1434130
Reviewed-by: emilio
MozReview-Commit-ID: EmnhkaA9RR5
Most of types just derive it using proc_macro directly. Some of value
types need manual impl.
In my current plan, this new trait will be used in bug 1434130 to expose
values as well.
Bug: 1455576
Reviewed-by: emilio
MozReview-Commit-ID: LI7fy45VkRw
