windows workflow use C drive as target directory
Currently we clone to drive D (default drive in GitHub Actions), then copy to drive C, then build from there (due to low disk space on D drive). In this PR instead of copying to C drive we only set `CARGO_TARGET_DIR` to C drive, the build is reading source files from D and writing target files to C drive. This gets us approx. -20min.
Try-windows build available [here](https://github.com/sagudev/servo/actions/runs/5219706997/jobs/9421863750).
What do we lose? Well copying step was good benchmarker for GitHub runner machines, fast windows machines spend ~5min in copying step while slow machines ~8min.
For the future: I do believe that D drive may be faster for writing, so switching roles could benefit us, but it will require slow (like copying step) clone.
Use layout 2020 by default
This PR switches `./mach build` to use layout 2020 by default. It doesn't switch the nightly builds served from download.servo.org to layout 2020. I can add that change to this PR if we are ready to make the switch in nightly builds as well.
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#29843
- [x] These changes do not require tests because modify mach build configuration.
Get clang-format from pip and upgrade to version 16
This allows relying on a specific version of clang-format and no longer use any version checks. In addition, we can use --dry-run -Werror in order to avoid having to run against every file individually.
Fix#29847.
Fix#29846.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `___` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#29847 and fix#29846.
- [x] These changes do not require tests because they update dev infrastructure.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
The flags stylo cares about reading and writing potentially at the same
time are disjoint, so there's no need for any strong memory ordering.
Differential Revision: https://phabricator.services.mozilla.com/D141829
This should be cheap and gives us a lot of memory savings for the page
on the bug, by deduplicating the inherited properties between parent and
children.
WebKit implements a similar optimization.
Differential Revision: https://phabricator.services.mozilla.com/D140826
If a name is not in self.seen, it means we've inherited it from our
parent. That in turn means that it can't have any variable reference
(because we inherit the computed variables) and we can skip the work of
traversing it, as we'd hit the early-return in traverse() anyways.
This doesn't fix the memory usage issue of the page on the bug, which
has a giant list of properties on the root and then a custom property
specified on all elements, but should significantly reduce the time we
spend iterating over custom properties for all those elements.
Differential Revision: https://phabricator.services.mozilla.com/D140825
As mentioned in bug 1747354, the location of the dist directory is
relied to be $topobjdir/dist, so just use that consistently rather
than getting it from a separate variable for rust build scripts.
Differential Revision: https://phabricator.services.mozilla.com/D136556
If the theme is dark but user prefers light pages, the background of the
tabpanel should arguably be light, since it can be seen across some
navigations.
Expose a -moz-content-prefers-color-scheme media query to chrome pages
so that our UI can correctly query it (and remove the unused -moz-proton
atom while at it).
Differential Revision: https://phabricator.services.mozilla.com/D136437
The issue here is that we end up with a transition between mismatched
transform lists that ends up generating an InterpolateMatrix {}
operation. So far so good, but we end up interpolating that a lot of
times and generating an unboundedly-deep operation list.
This implementas an optimization that flattens them to a single matrix
when possible (when there's no dependencies on the containing box).
This is similar to:
https://chromium.googlesource.com/chromium/src.git/+/2b89cc4df436e672ef9cf940d1c0dc73fef82a4a
We fix the to_pixel_length() behavior for LenghtPercentage to be
correct (and update callers to preserve behavior).
Differential Revision: https://phabricator.services.mozilla.com/D134784
Hashbrown grows a lot sometimes making us waste a lot of memory. Shrink
some of these maps after CascadeData rebuild / stylesheet collection
invalidation.
Differential Revision: https://phabricator.services.mozilla.com/D134716
The only remaining consumers are ::-moz-tree pseudo-elements (we used to
use ThinBoxedSlice for other data structures in the past).
Those are not particularly performance sensitive so I think just
double-boxing is fine. In the future, if we wanted to avoid the double
indirection, we could probably use the "thin" crate
(https://docs.rs/thin) or similar, which stores the length of the slice
along with the allocation, making the pointer thin in all
configurations, much like "ThinArc" does:
https://searchfox.org/mozilla-central/rev/1ce2eea39442190a71a1f8f650d098f286bf4a01/servo/components/servo_arc/lib.rs#891
In practice though, I don't think it's particularly worth it for this
specific case.
Differential Revision: https://phabricator.services.mozilla.com/D134672
By modeling it as a separate layer that behaves somewhat specially.
See https://github.com/w3c/csswg-drafts/issues/6872.
The remaining revert-layer tests that we fail are because either we
don't implement a feature (like @property) or because it's used in
keyframes (where revert is a bit unspecified and we have existing
issues with it).
Differential Revision: https://phabricator.services.mozilla.com/D133373
This patch looks bigger than it is, but it's mostly because
of plumbing.
To implement revert-layer we need not only the cascade origin of the
declaration, but the whole cascade level, plus also the layer order.
In order to do this, encapsulate these two things inside a 32-bit
`CascadePriority` struct and plumb it through the rule tree and so on.
This allows us to remove the packing and unpacking of CascadeLevel,
though I kept the ShadowCascadeOrder limit for now in case we need to
reintroduce it.
Fix `!important` behavior of layers while at it (implementing it in
`CascadeLevel::cmp`, spec quote included since it was tricky to find)
since some revert-layer tests were depending on it.
The style attribute test is failing now, but follow-up commit fixes
it, see spec issue.
In terms of the actual keyword implementation, it's sort of
straight-forward: We implement revert and revert-layer in a shared
way, by storing the cascade priority that reverted it.
Differential Revision: https://phabricator.services.mozilla.com/D133372
