It seems that the result of hash algorithm used in bloom filter depends
on the pointer length. On 64bit platforms, there are 135 false positives
in the first part of that test, and 8 in the second part. However, on
32bit platforms, the numbers become 157 and 16 correspondingly.
16 is still less than 20% in the second part, so all fine, but 157 is
slightly larger than 15% in the test assertion. Given it is what we are
shipping, we probably should just accept this and loosen the assertion.
MozReview-Commit-ID: 9kFXBzLFAzE
--HG--
extra : rebase_source : 41fa45dc3c59b2f44d33bdbe86b3eb2e29a31319
Now that rustfmt is getting close to stable, and work on the style system has died down a bit, it seemed like an opportune time to auto-format the style crates.
The first commit disables import reordering, since tidy and rustfmt don't currently agree on the correct ordering. The second commit does a bunch of manual fixups such that the output of rustfmt passes tidy. The third commit runs rustfmt on the three aforementioned crate.
There are a few dozen warnings in the style crate about lines longer than 100 characters. It would be good to fix these, but I don't have time for that now.
Source-Repo: https://github.com/servo/servo
Source-Revision: 9a900ef019cd643bff961d7b20db6da69f3edb29
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2b228d52a084bc832444ac686290840c4369f98d
We could invalidate in a slightly more fine-grained way, but I don't think it's
worth the churn vs. keeping the special-cases minimal.
Bug: 1452640
Reviewed-by: xidorn
MozReview-Commit-ID: 5DkQrgwg9GW
Source-Repo: https://github.com/servo/servo
Source-Revision: e11c2d97552d192b761b0684c8c6852b9dea0921
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 00941db97d18fcbea845f225d318eae4d47aab22
Kinda tricky because :host only matches rules on the shadow root where the rules
come from. So we need to be careful during invalidation and style sharing.
I didn't use the non_ts_pseudo_class_list bits because as soon as we implement
the :host(..) bits we're going to need to special-case it anyway.
The general schema is the following:
* Rightmost featureless :host selectors are handled inserting them in the
host_rules hashmap. Note that we only insert featureless stuff there. We
could insert all of them and just filter during matching, but that's slightly
annoying.
* The other selectors, like non-featureless :host or what not, are added to the
normal cascade data. This is harmless, since the shadow host rules are never
matched against the host, so we know they'll just never match, and avoids
adding more special-cases.
* Featureless :host selectors to the left of a combinator are handled during
matching, in the special-case of next_element_for_combinator in selectors.
This prevents this from being more invasive, and keeps the usual fast path
slim, but it's a bit hard to match the spec and the implementation.
We could keep a copy of the SelectorIter instead in the matching context to
make the handling of featureless-ness explicit in match_non_ts_pseudo_class,
but we'd still need the special-case anyway, so I'm not fond of it.
* We take advantage of one thing that makes this sound. As you may have
noticed, if you had `root` element which is a ShadowRoot, and you matched
something like `div:host` against it, using a MatchingContext with
current_host == root, we'd incorrectly report a match. But this is impossible
due to the following constraints:
* Shadow root rules aren't matched against the host during styling (except
these featureless selectors).
* DOM APIs' current_host needs to be the _containing_ host, not the element
itself if you're a Shadow host.
Bug: 992245
Reviewed-by: xidorn
MozReview-Commit-ID: KayYNfTXb5h
Source-Repo: https://github.com/servo/servo
Source-Revision: cb754b262747e7cab794411df55588f0f0b30b5e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2ebbb2578ff9dbadfe905ae501cd52bd61a9fe9a
This changes the order to match the normal selector-matching order, which is
usually faster.
That is, when matching div:nth-child(2), for example, before this patch we'd
first try to match :nth-child(2), and only then div.
This patch makes us walk until the end or the next combinator, and only then
match backwards, matching first div, then :nth-child.
Bug: 1443814
Reviewed-by: bholley
Source-Repo: https://github.com/servo/servo
Source-Revision: 8e52f8a523e2f12b2666536d0f8ff3fa40b83ef5
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 4b8b140e54485fb2762745f13af285c640d39254
This fixes the test from https://github.com/w3c/web-platform-tests/pull/9212 in
Gecko.
Source-Repo: https://github.com/servo/servo
Source-Revision: 82922c97dc0313736fedb8021b205d4f84088a15
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : ec1b0b5dcf36a50fe9b1cd5b087efb5f665cc79e
See each commit individually.
Source-Repo: https://github.com/servo/servo
Source-Revision: 6fc71a7644bd7afcccf83f67cfdaf01897e1a3bc
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 61fb59e354c7ad8307d6f76b93bd365abc575c85
This fixes bugs where we're not passing the value around correctly, like from
::-moz-any.
This is a fix for https://bugzilla.mozilla.org/show_bug.cgi?id=1431539.
Source-Repo: https://github.com/servo/servo
Source-Revision: 0d7d02fca772a407d4ffa1ebd1e03d60f385eb74
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : c3d27604818f36b68c16d53ef143b4ef892c006e
This is the "better way" I mentioned in #19774, which seems to actually improve the score of dromaeo_css on talos.
Source-Repo: https://github.com/servo/servo
Source-Revision: 525758ea5ef67148c28acae9404916691e9a960c
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 0d5d151d5cadca6bf2feed3e0fe463a1b02e753d
Don't use it yet (since I was working from a Servo tree). Will hook it up and improve in the Gecko bug.
Right now it takes a `StyleRuleCascadeData`, which means that if all the origins in the document have state selectors we could do just one walk over the tree and not multiple, that will be improved.
Other than that, this is completely untested of course, but I prefer to land it, given I don't think it's complex, and work on the Gecko integration separately. The reason for this is that I also plan to fix the `<slot>` bugs, which will change `StyleRuleCascadeData` and such, and I want the two bugs to conflict as little as possible.
Source-Repo: https://github.com/servo/servo
Source-Revision: 50e4171958d4ff7f1c76d133a8f89e7d5995376f
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 4f1c7698b9912d4782d744a4dbd9e80afa7fe0cf
This allows to selector-match ::slotted, though we still don't parse it.
Bug: 1425834, 1424607, 1425755
Reviewed-by: heycam
MozReview-Commit-ID: ItELHkf2PMl
Source-Repo: https://github.com/servo/servo
Source-Revision: bb34b7f54aa85cde600c6d675360d03714cf1f8b
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : c92bde66c55c112ea537384d89a698ccb5eba798
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.
Source-Repo: https://github.com/servo/servo
Source-Revision: f5129ef7b5efa59a176cac98dc68d910cb3279c9
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 5f956f568b12d8aa7611bc05ac7b1d1497689189
I'll need this for ::slotted().
Source-Repo: https://github.com/servo/servo
Source-Revision: c6bf85eca90b9cb71ff05d4454a43a7da5fc3ac8
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 02f9868af7469734b70d02e8ddb0470a9c8d407d
Also drop a few FIXMEs while at it, since they look bogus.
Source-Repo: https://github.com/servo/servo
Source-Revision: 051eb6bcb9204ecab1c1481a275a09fd50bf0467
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 049f90ddd1ae37e05adec201fbaa6f876cbdddfe
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.
Source-Repo: https://github.com/servo/servo
Source-Revision: 7a8733723551201d2c06acde9b0915b4c03938b4
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 00a655d0bcdf9cec70330c34eea0756b73c38cc3
`:dir()` pseudo class param now represented as enum variants.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#16840
- [X] There are tests for these changes
Source-Repo: https://github.com/servo/servo
Source-Revision: 006202732f0bd8d2239bdd51898380bdbe0f0f1a
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : e9778d171eef1db2ebbf52b99d3255d50b2a60ec
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
Source-Repo: https://github.com/servo/servo
Source-Revision: 85fa6409bb699647b4f5e22952538365e87418d7
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 156224040ad2191714b888e91c9b555e7efc9bb6
See #19128, this part is cherry-picked so Gecko can build with rust nightly.
Source-Repo: https://github.com/servo/servo
Source-Revision: e7a654dd13f589e127193267bcb576ffd661c11d
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 0ee67ddf598b1ea99e92f6a285a960f86b1cb971
See #18809
Still haven't had time to test it but it should fix the tests failures that appeared in m-c
Source-Repo: https://github.com/servo/servo
Source-Revision: fe4139b779b3af749ec1426ddf4e1393c7b85442
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 9a0549d7dd8a99315ba3f8eec5d0f9fdf9eb4c0f
I was doing something unrelated with this code, and each signature uses a
different style. This PR unifies them.
Source-Repo: https://github.com/servo/servo
Source-Revision: a296e386af21b50409e78dd3a34ea6a5fd36d4bf
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : c783db0edd806e491f49edd8e11a50d710e0a910
This avoids unnecessary UTF-8 validation on OsStrings that we just pass
back to the OS.
---
- [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 they are code cleanup only
Source-Repo: https://github.com/servo/servo
Source-Revision: 5ab0ac162019aede12a8150118328566467fddf2
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : c2249af39376e580dd2df6ed2ef943f16abe9fb6
This is the Servo side change of [bug 1397644](https://bugzilla.mozilla.org/show_bug.cgi?id=1397644).
Source-Repo: https://github.com/servo/servo
Source-Revision: b1e6f05ae455748f6091ddf81c1c0488e09546a1
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : bccb30f361f44fe3da55d5f4fe7c0cde61550524
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
Source-Repo: https://github.com/servo/servo
Source-Revision: fe16c1d5c3c9084da0ccb85af599d6ec0f8ab20b
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : bb9d52a22bee6d1fe773718f649c977b07840719
