style: Use the ? operator for Option
This is stable in Rust 1.22 (#19532).
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes do not require tests because it is refactoring only
<!-- 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/19537)
<!-- Reviewable:end -->
selectors: Simplify :visited by only using the "is inside link" information.
Right now we go through a lot of hoops to see if we ever see a relevant link.
However, that information is not needed: if the element is a link, we'll always
need to compute its visited style because its its own relevant link.
If the element inherits from a link, we need to also compute the visited style
anyway.
So the "has a relevant link been found" is pretty useless when we know what are
we inheriting from.
The branches at the beginning of matches_complex_selector_internal were
affecting performance, and there are no good reasons to keep them.
I've verified that this passes all the visited tests in mozilla central, and
that the test-cases too-flaky to be landed still pass.
<!-- 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/19520)
<!-- Reviewable:end -->
Right now we go through a lot of hoops to see if we ever see a relevant link.
However, that information is not needed: if the element is a link, we'll always
need to compute its visited style because its its own relevant link.
If the element inherits from a link, we need to also compute the visited style
anyway.
So the "has a relevant link been found" is pretty useless when we know what are
we inheriting from.
The branches at the beginning of matches_complex_selector_internal were
affecting performance, and there are no good reasons to keep them.
I've verified that this passes all the visited tests in mozilla central, and
that the test-cases too-flaky to be landed still pass.
According to the spec, this parser should follow what we do for
@font_face rule, so we use the same type to parse the input, instead of
using the parser of their specified values.
stylo: Implement Servo_ParseTransformIntoMatrix
This is an inter-dependent patch of Bug 1408310.
DOMMatrix needs to convert a specified transform list into a matrix, so we rewrite
to_transform_3d_matrix by generics for both specified and computed transform lists.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix [Bug 1408310](https://bugzilla.mozilla.org/show_bug.cgi?id=1408310).
- [X] These changes do not require tests because we can count on the wpt tests for DOMMatrix on Gecko side.
<!-- 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/19388)
<!-- Reviewable:end -->
DOMMatrix needs to convert a specified transform list into a matrix, so
we could rewrite to_transform_3d_matrix by generics for both specified
and computed transform lists.
Besides, we have to update the test case because we use Transform3D<f64> to
compute the matrix, instead of Transform3D<f32>, so the result will be
the same as that in Gecko. Using 0.3 may cause floating point issue
because (0.3f32 as f64) is not equal to 0.3 (i.e. floating point precision
issue), so using 0.25 instead.
style: Bring back the optimization to avoid traversing XBL subtrees that will likely change.
Bug: 1420496
Reviewed-by: heycam
MozReview-Commit-ID: 3sIGtcVOt0r
<!-- 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/19380)
<!-- Reviewable:end -->
