In the upcoming patches we'll eliminate the existing Selector and SelectorInner,
and ComplexSelector will become an Arc-managed |Selector|. So the tuple-indexed
setup is just temporary.
MozReview-Commit-ID: 4CcOYeHGUED
Bump euclid to 0.13 and heapsize to 0.4
This is necessary for the serde 1.0 update.
--
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [ ] These changes fix #__ (github issue number if applicable).
- [X] These changes do not require tests because it's just a dependency bump
<!-- 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/17104)
<!-- Reviewable:end -->
To support visited styles, we match and cascade a separate set of styles any
time we notice that an element has a relevant link.
The visited rules and values are held in `ComputedStyle` alongside the
regular rules and values, which simplifies supporting various APIs like
`cascade_primary_and_pseudos` which expect easy access to previously matched
rules.
To simplify passing the additional values around, an additional reference to the
visited `ComputedValues` is placed inside the regular `ComputedValues`.
MozReview-Commit-ID: 2ebbjcfkfWf
Adjust the matching process to look for a "relevant link" while matching. A
"relevant link" is the element being matched if it is a link or the nearest
ancestor link.
Matching for links now depends on the `VisitedHandlingMode`, which determines
whether all links match as if they are unvisited (the default) or if the
relevant link matches as visited (and all others remain unvisited).
If a relevant link is ever found for any selector, track this as part of the
`MatchingContext` object. This is used in the next patch to determine if an
additional match and cascade should be performed to compute the styles when
visited.
MozReview-Commit-ID: 3xUbRo7vpuD
It's unfortunate, but it's a correctness issue. I was looking at the
expectations update here:
* 659cddddd4
And investigating it I realised that it's wrong to coalesce selectors like that,
because we keep the bloom filter flags.
So in the test cases disabled, we have a selector that looks like this:
msub > :not(:first-child),
msup > :not(:first-child),
msubsup > :not(:first-child),
mmultiscripts > :not(:first-child) {
-moz-script-level: +1;
-moz-math-display: inline;
}
And an element that looks like this:
<msubsup><mi></mi><mi></mi></msubsup>
We're only inserting the first selector msub > :not(:first-child) into the set,
so when we're going to match the <mi> elements we fast-reject it in both cases
due to the bloom filter, so they share style.
I can't see an easy way to fix this keeping the deduplication. If we keep it, we
need to remove the bloom filter optimization, which means that we'd trash the
cache for every first-child in the document (the :not(:first-child) effectively
becomes a global rule).
MozReview-Commit-ID: 9VPkmdj9zDg
Signed-off-by: Emilio Cobos Álvarez <emilio@crisal.io>
These are never stored persistently anywhere, and I'm pretty sure it's slower
for the compiler/CPU to operate on non-word-sized flags.
MozReview-Commit-ID: LQNsJbUsw85
This significantly reduces realloc time at the expense of some additional
mmemmoves, but pencils out to a small win on my machine.
We wanted to do this anyway, and this avoids needing to remove the smallvec
dependency from Selectors and then add it back again.
MozReview-Commit-ID: HW4kDxzLACp
