Make doc comments not truncated again.
`rustdoc --passes "collapse-docs unindent-comments"` doesn’t work is intended. It still generate HTML files that look alright at a glance, but all doc-comments are truncated to their first line for some reason I don’t understand.
See http://doc.servo.org/script/dom/index.html for example. The module documentation there is currently just “The implementation of the DOM.”, but clicking the [src] link shows a much larger doc-comment.
The correct invocation is to use `--passes` multiple times.
https://github.com/rust-lang/rust/issues/15347#issuecomment-122785714
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6668)
<!-- Reviewable:end -->
`rustdoc --passes "collapse-docs unindent-comments"` doesn’t work is intended.
It still generate HTML files that look alright at a glance,
but all doc-comments are truncated to their first line
for some reason I don’t understand.
See http://doc.servo.org/script/dom/index.html for example.
The module documentation there is currently just
“The implementation of the DOM.”, but clicking the [src] link
shows a much larger doc-comment.
https://github.com/rust-lang/rust/issues/15347#issuecomment-122785714
The correct invokation is to use `--passes` multiple times.
Implement Range#insertNode
Gecko doesn't really follow the spec but it seems to throw a HierarchyRequest error when parent is null.
Any ideas who I should talk to about fixing the spec to account for the null checks?
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6568)
<!-- Reviewable:end -->
It is a field that is used a function argument. Given that the control flow
is not quite the same, and we can't add an argument to Send, I opted for a
separate function.
Wire up the JS engine's memory reporting.
SpiderMonkey provides an extremely fine-grained breakdown of memory
usage, but for Servo we aggregate the measurements into a small number
of coarse buckets, which seems appropriate for the current level of
detail provided by Servo's memory profiler. Sample output:
```
| 17.41 MiB -- url(file:///home/njn/moz/servo/../servo-static-suite/wikipedia/Guardians%20of%20the%20Galaxy%20(film)%20-%20Wikipedia,%20the%20free%20encyclopedia.html)
| 7.32 MiB -- js
| 3.07 MiB -- malloc-heap
| 3.00 MiB -- gc-heap
| 2.48 MiB -- used
| 0.34 MiB -- decommitted
| 0.09 MiB -- unused
| 0.09 MiB -- admin
| 1.25 MiB -- non-heap
```
Most of the changes are plumbing to get the script task communicating
with the memory profiler task.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6572)
<!-- Reviewable:end -->
Don't crash when Firefox doesn't send autoMargins.
Firefox Developer Tools doesn't always send autoMargins, as seen in this message:
{"type":"getLayout","node":"node14","to":"pageStyle9"}
So don't use unwrap.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6637)
<!-- Reviewable:end -->
gfx: Make display lists serializable using `serde`.
This commit introduces the `serde` dependency, which we will use to
serialize messages going between processes in multiprocess Servo.
This also adds a new debugging flag, `-Z print-display-list-json`,
allowing the output of display list serialization to be visualized.
This will be useful for our experiments with alternate rasterizers.
r? @metajack
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6583)
<!-- Reviewable:end -->
This commit introduces the `serde` dependency, which we will use to
serialize messages going between processes in multiprocess Servo.
This also adds a new debugging flag, `-Z print-display-list-json`,
allowing the output of display list serialization to be visualized.
This will be useful for our experiments with alternate rasterizers.
GLRasterizationContext is now responsible for doing GPU rasterization.
It can coexist with its target NativeSurface, so we don't have to
continually recreate NativeSurfaces when doing GPU rasterization.
