This won't reintroduce any of the regressions that were triggered by our
previous attempts to turn off -moz prefixed gradients, and lets us massively
simplify the gradient code, if it sticks.
Differential Revision: https://phabricator.services.mozilla.com/D29346
I want to do this so that I can get rid of Either<>. The reasons for getting rid
of either are multiple:
* It doesn't generate as nice C++ code using cbindgen.
* It isn't that nice to use either from Rust.
* cbindgen has bugs with zero-sized types.
I started using this for ColorOrAuto and a few others, for now.
Differential Revision: https://phabricator.services.mozilla.com/D19844
It does not represent `<length> | <percentage>`, but `<length-percentage>`, so
`LengthOrPercentage` is not the right name.
This patch is totally autogenerated using:
rg 'LengthOrPercentage' servo | cut -d : -f 1 | sort | uniq > files
for file in $(cat files); do sed -i "s#LengthOrPercentage#LengthPercentage#g" $file; done
Differential Revision: https://phabricator.services.mozilla.com/D15812
This matches the spec, https://drafts.csswg.org/css-values/#angles, which says:
> All <angle> units are compatible, and deg is their canonical unit.
And https://drafts.csswg.org/css-values/#compat, which says:
>When serializing computed values [...], compatible units [...] are converted into a single canonical unit.
And also other implementations (Blink always serializes angles as degrees in
computed style for example).
Also allows us to get rid of quite a bit of code, and makes computed angle value
representation just a number, which is nice.
Differential Revision: https://phabricator.services.mozilla.com/D8619
This commit adds the multi-position gradient color-stops syntax.
GradientItem::parse_comma_separated is extended to attempt to parse
a LengthOrPercent after each color stop. If it succeeds, it appends
an additional color stop with a duplicate color and the specified
position.
This change is only to the parsing, serialization is left unchanged
as per [1].
[1] https://github.com/w3c/csswg-drafts/issues/2714
Differential Revision: https://phabricator.services.mozilla.com/D7380
There were a check in CssUrl::parse_from_string for extra data, which
was removed as part of servo/servo#16241, so it never fails now.
CssUrl::from_url_value_data doesn't seem to need Result from the very
beginning. It is unclear why it was made that way.
Bug: 1461858
Reviewed-by: emilio
MozReview-Commit-ID: LXzKlZ6wPYW
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
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.
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.
Normally, we should not serialize if the line direction points downwards. Unprefixed and
-webkit- prefixed syntaxes use only Keyword enum for line direction and we check them already.
But -moz- prefixed linear gradients can store position too. Therefore it's stored inside
`LineDirection::MozPosition` and we should check that for consistency between other gradients.
This patch replaces the handwritten MallocSizeOf implementation for
PropertyDeclaration with a derived one, which gives much more thorough
measurement.
This requires (a) deriving MallocSizeOf for a *lot* of additional types (most
of which already have `derive(HeapSizeOf)` in Servo builds), and (b)
implementing MallocSizeOf for a few more types in the `malloc_size_of` crate.
These changes would significantly improve the reporting coverage for gmail if
it weren't for the fact that SpecifiedUrl isn't measured due to a lack of
clarity about its fields; that can be fixed as a follow-up once bug 1397971 has
landed.
The default linear gradient direction is `to bottom`. This correspondes to
`top` keyword in prefixed linear gradients. We should preserve the default value.
