It used to be the case that MatchingContext was immutable and thus we didn't
care to have accessors.
This is no longer true, so let's make this code a bit nicer.
Without turning it on yet, of course.
The reason why I didn't use the general PseudoElement mechanism is because this
pseudo is a bit of its own thing, and I found easier to make ::selectors know
about it (because you need to jump to the assigned slot) than the other way
around.
Also, we need to support ::slotted(..)::before and such, and supporting multiple
pseudo-elements like that breaks some other invariants around the SelectorMap,
and fixing those would require special-casing slotted a lot more in other parts
of the code.
Let me know if you think otherwise.
I also don't like much the boolean tuple return value, but I plan to do some
cleanup in the area in a bit, so it should go away soon, I'd hope.
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.
These methods are instantiated by the Gecko library, and used during
querySelector, which means that they end up being super-hot in micro-benchmarks.
MozReview-Commit-ID: K1XJb0QyX5a
Update bitflags to 1.0 in every servo crate
It still needs dependencies update to remove all the other bitflags
versions.
- [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's a dependency update
<!-- 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/18809)
<!-- Reviewable:end -->
This type is a lot of complexity related to a very specific thing such as the
hover and active quirk.
Instead of that, move `nesting_level` to `MatchingContext`, and simplify all
this computing whether the quirk applies upfront, for each complex selector we
test.
This is less error-prone, and also allows simplifying more stuff in a bit.
Selector-matching can backtrack when looking for ancestor combinators, so we
can't just arrive there once and forget.
Also, there was a further problem before this patch, which was that
note_next_sequence was called _before_ checking whether all simple selectors
matched, so the sequence you could get there is just wrong.
Bug: 1384020
Reviewed-by: canaltinova
MozReview-Commit-ID: 6g0ibb8EfBU
Otherwise, tests like the following fail, given we always match as unvisited,
and we'd never mark the link as needing invalidation.
<!doctype html>
<style>
a {
color: red !important;
}
.foo :visited {
color: green !important;
}
</style>
<div>
<a href="https://google.es">visit me</a>
<button onclick="this.parentNode.className = 'foo'">Then click me</button>
</div>
Bug: 1368240
MozReview-Commit-ID: LDv6S28c4ju
