style: Support anonymous box pseudo-elements
This is a work-in-progress that:
* Adds support for some pseudo-elements to skip the cascade entirely, in an analogous way to Gecko's anonymous box pseudo-elements.
* Takes rid of `StylistWrapper`, and uses `Arc::get_mut` instead.
* Uses the first bullet to precompute the `-servo-details-content` pseudo's style.
I'd like @bholley to take a look before following, do you think that the aproach is the correct?
Also, @SimonSapin could want to put some eyes on it.
Depends on https://github.com/servo/rust-selectors/pull/81
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/10815)
<!-- Reviewable:end -->
Extracted shorthands to separate files.
Following up on #10813, here is a similar extraction of the shorthand stuff as well.
I've deliberately tried to keep things similarly structured as in the longhand files. I.e. if a given property is in e.g. longhand/box.mako.rs, the shorthand stuff that relates to the same property is in shorthand/box.mako.rs and so forth.
----
The file is now down from ~7000 LoC to ~1750. A big improvement in my eyes, but there's still room for improving more. However, that shouldn't be done until we've had a bit of discussion about it. What we've done so far has been more-or-less obvious (after resolving the underlying Python/Mako issues with how to get things to properly communicate when things got split into multiple files etc). The remaining stuff is basically a plethora of anything from enums to structs to impls to... you name it.
One way to try and sort this out is to continue abusing Mako %include:s for this. I'm not sure it's the right way, but it would be a reasonably _easy_ way to do it. Another way would be to use Rust modules/crates etc. for sorting it out. I feel like too much of a novice on the Rust side of stuff yet to have any sensible opinions on how to get that done, so here I'd very much like suggestions from other people in the project.
(This is more of an entry point for discussion, and we could very well move that to a separate issue if you like. I think the more important short-term point is to try and get this merged. 😊 Please let me know if you feel it is OK, and if not, feel free to suggest adjustments.)
<!-- Reviewable:start -->
---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/servo/10863)
<!-- Reviewable:end -->
While we're here we also:
* remove any code conditional on style_struct.gecko_ffi_name, since all
style structs now do have a corresponding Geckos struct
* add new UIReset and XUL style structs, so that all Gecko structs are
now present (apart from Variables, which is special)
* Sections like `[dependencies.foo]` can be entries in a `[dependencies]`
section with the `{key = value}` syntax.
* Per-target dependencies can be expressed with more general `cfg(…)`
conditions instead of exact target triples:
https://github.com/rust-lang/cargo/pull/2328
I've deliberately tried to keep things similarly structured as in the longhand files. I.e. if a given property is in e.g. longhand/box.mako.rs, the shorthand stuff that relates to the same property is in shorthand/box.mako.rs and so forth.
Sorry for the bulk size of this; I know already it's not going to be a fun thing to review. Nevertheless, it should be done so we finalize the split of this huge file into smaller, more maintable parts.
The content of stuff being moved to separate files is unchanged. Only some minor formatting changes have been made and similar, but nothing of particular interest. IMHO it should be safe to merge if all the tests are fine.
Added #[allow(unused_extern_crates)] to silence false positives
* bitflags, lazy_static and matches because macro_use
* alloc_jemalloc because builtin crate
See https://github.com/rust-lang/rust/issues/30849
The spec has changed a bit since the servo implementation. We still need to alias
sideways-right to sideways and add other writing modes, but we can do that later.
This is a new attempt of #10586, after Simon Sapin's great cleanups in #10749 has landed. I have adjusted the changes to the new structure that was introduced, and also only done a few of the longhand ones. Will certainly continue on this as soon as we have a basic agreement that this style is reasonable.
