As I said over bug 1549593, the eventual goal is to use ArcSlice in all
inherited properties. But this seemed like a good first candidate that doesn't
require me to move around a lot more code, since we were already using cbindgen
for the path commands.
Differential Revision: https://phabricator.services.mozilla.com/D30134
This enables destructors for tagged unions in cbindgen, implemented in:
* https://github.com/eqrion/cbindgen/pull/333
Which allow us to properly generate a destructor for the cbindgen-generated
StyleBasicShape (which now contains an OwnedSlice).
For now, we still use the glue code to go from Box<BasicShape> to
UniquePtr<BasicShape>. But that will change in the future when we generate even
more stuff and remove all the glue.
I could add support for copy-constructor generation to cbindgen for tagged
enums, but I'm not sure if it'll end up being needed, and copy-constructing
unions in C++ is always very tricky.
Differential Revision: https://phabricator.services.mozilla.com/D29769
I thought a bit about how to test it and it's not particularly great.
test_css_parse_error_smoketest.html is great to assert that something _gets_
reported, but not that it doesn't :)
Differential Revision: https://phabricator.services.mozilla.com/D30201
Also, buffer the errors, since we're going to want to look at the whole
declaration block to skip reporting them.
This shouldn't change behavior, just moves some work to the caller, and defers a
bit the work so that it happens only when error reporting is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D30200
The initial value for this is indeed `none` (and thus empty). The Rust code was
confused.
This property is disabled by default these days, and I think the
get_initial_value() function, which is what could get confused, is not called
for this property, so I think this shouldn't be observable.
Differential Revision: https://phabricator.services.mozilla.com/D30124
Converting the NS_STYLE_BORDER definitions in to enumerated classes as
per bug 1277133.
The original constants broke the convention used by the rest of the
definitions as the CSS property being described is `border-collapse`,
so corrections were made with the migration to the enumerated class.
Differential Revision: https://phabricator.services.mozilla.com/D29951
The previous commit removed the dependence on the discriminant value, so we
don't need to keep discriminants different from text-align anymore.
Differential Revision: https://phabricator.services.mozilla.com/D29361
The text-decoration-line is a drive-by thing, but I can put it in a separate
patch if you want. It was needed for Servo (to compute
-servo-text-decorations-in-effect), but I moved Servo away from that model a
while ago.
Differential Revision: https://phabricator.services.mozilla.com/D26254
We don't have lossy currentcolor in the style system anymore, except for a
single property -moz-font-smoothing-background-color.
I could've converted it into a proper StyleColor and thread down all the
necessary information to the font metrics code.
But it doesn't really seem worth it given it's not exposed to the web, so I just
did the simplest thing, which is making currentcolor compute to transparent to
that specific property.
This patch also removes the stores_complex_colors_lossily code and related,
since now we always can cache computed colors.
Differential Revision: https://phabricator.services.mozilla.com/D26187
To be more similar between Rust and C++. This introduces GenericFontFamily and
exposes that plus FontFamilyNameSyntax to C++, using that where appropriate
instead of plain uint8_t as we were doing.
As a follow-up, as discussed on IRC with Jonathan, we can remove the -moz-fixed
family, and turn it just into an alias of Monospace.
The only non-trivial change is the MatchType changes, but they're ok I think.
The code already assumed at most one CSS generic, and the struct still takes 8
bits. I've verified that the relevant tests are passing (though try is closed).
Differential Revision: https://phabricator.services.mozilla.com/D24272
This avoids having to support storing refcounted URLValue objects in shared memory,
which would be tricky.
Depends on D17183
Differential Revision: https://phabricator.services.mozilla.com/D17184
UA style sheets only ever specify a single generic font family in font-family
properties, so we pre-create a unique, static SharedFontList for each generic
and change the representation of FontFamilyList to be able to refer to them
by their generic ID. This avoids having to share refcounted SharedFontList
objects across processes.
Differential Revision: https://phabricator.services.mozilla.com/D17183
This reduces a lot the boilerplate that's needed in order to add simple binding
functions.
This starts using &Foo and Option<&Foo> instead, and as a result we need to
remove the servo_function_signatures test, which is a bit unfortunate.
I think it's worth though, this causes problems on some platforms (see bug
1534844), and messing up the functions signature is not something that I've ever
seen (other than bug 1308234, which already had all the FooBorrowed mess which
I'm removing).
Also, cbindgen understands references and Option<&Foo>, so it will be the way to
go in the future.
After this patch we can also remove HasSimpleFFI, but I've kept it for now since
I still use it in a few places, and this patch is quite big on its own.
Differential Revision: https://phabricator.services.mozilla.com/D24092
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
