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.
