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 -->
Use byte indices instead of char indices for text runs
Replace character indices with UTF-8 byte offsets throughout all code dealing with text runs. This eliminates a lot of complexity when converting from one to the other, and interoperates better with the rest of the Rust ecosystem.
For most code this is just a simple replacement of char indices with byte indices. In a few places like glyph storage and text fragment scanning, it also lets us get rid of code that existed only to map between bytes and chars.
Also includes some related fixes to text shaping, discovered while working on this conversion. See the commit messages for details.
r? @pcwalton
<!-- 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/10895)
<!-- Reviewable:end -->
[10743] Fix namespace in createDocument test
[10743] Remove test ini file, match returns static strings instead of DOMString.
[10743] Fix arguments to XMLDocument::new
Update failing test
[10743] Add content type to XmlDocument constructor based on namespace
[10743] Fix namespace in createDocument test
[10743] Remove test ini file, match returns static strings instead of DOMString.
[10743] Fix arguments to XMLDocument::new
Update failing test
Replace character indices with UTF-8 byte offsets throughout the code dealing
with text shaping and breaking. This eliminates a lot of complexity when
converting from one to the other, and interoperates better with the rest of
the Rust ecosystem.
Fix logic for cors cache match
The current logic for a cors cache match does not consider "credentials is false and request's credentials mode is not "include" or credentials is true."
I could have missed something, but `CacheRequestDetails::credentials` is set to true if credentials mode is "include", and false otherwise. So `(!cors_cache.credentials && !cors_req.credentials) || cors_cache.credentials` would be directly following the spec, but unless I'm mistaken `cors_cache.credentials || !cors_req.credentials` is logically the same.
Fixes: #10525
<!-- 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/10867)
<!-- Reviewable:end -->
script: Make iframes know their pipeline IDs at all times, even after navigation.
Since WebRender uses the pipeline ID stored in the iframe element to
determine which pipeline to display, it had better be kept up to date!
Closes#9919.
r? @jdm
<!-- 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/10159)
<!-- Reviewable:end -->
navigation.
Since WebRender uses the pipeline ID stored in the iframe element to
determine which pipeline to display, it had better be kept up to date!
Closes#9919.
This is a no-op, since a "non-glyph" is simply `GlyphEntry(0)`. This is the
same as `GlyphEntry::initial()`, which all the entries are already initialized
to.
Shaper::save_glyph_results incorrectly starts its loop by setting glyph_span
to a length of 1. This means that the `if glyph_span.len() == 0` test in the
inner loop will never succeed.
Instead the glyph span should start out empty, and a glyph should be added only
as the corresponding char is found. For comparison, see the Gecko code this
was ported from:
https://hg.mozilla.org/mozilla-central/file/ab0044bf/gfx/thebes/gfxHarfBuzzShaper.cpp#l1682
Code cleanup in gfx::text
* Fix deprecation warnings by replacing `str::char_at` and related functions with iterators.
* Replace some uses of `range::Range` with `std::ops::Range`.
<!-- 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/10880)
<!-- Reviewable:end -->
Add a method for dumping profiles as self-contained HTML w/ timeline visualization
This commit adds the `--profiler-trace-path` flag. When combined with `-p` to
enable profiling, it dumps a profile as a self-contained HTML file to the given
path. The profile visualizes the traced operations as a Gantt-chart style
timeline.
Example output HTML file: http://media.fitzgeraldnick.com/dumping-grounds/trace-reddit.html
Mostly I made this because I wanted to see what kind of data the profiler has, and thought that this might be useful for others as well. I'm happy to add tests if we can figure out how to integrate them into CI, but I'm not sure how that would work.
Thoughts?
<!-- 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/10694)
<!-- Reviewable:end -->
This commit adds the `--profiler-trace-path` flag. When combined with `-p` to
enable profiling, it dumps a profile as a self-contained HTML file to the given
path. The profile visualizes the traced operations as a gant-chart style
timeline.
