Fail on unrecognized debug option
Refs: https://github.com/servo/servo/issues/7142
Ran some basic functional tests:
```
$ ./mach run -d -Z bubble-widths,disable-canvas-aa,trace-layout tests/ref/blur_ref.html
$ ./mach run -d -Z help
Usage: /Users/greg/servo/target/debug/servo debug option,[options,...]
where options include
Options:
bubble-widths Bubble intrinsic widths separately like other engines.
disable-text-aa Disable antialiasing of rendered text.
disable-canvas-aa Disable antialiasing on the HTML canvas element.
dump-flow-tree Print the flow tree after each layout.
dump-display-list Print the display list after each layout.
dump-display-list-json Print the display list in JSON form.
dump-display-list-optimized Print optimized display list (at paint time).
relayout-event Print notifications when there is a relayout.
profile-tasks Instrument each task, writing the output to a file.
show-compositor-borders Paint borders along layer and tile boundaries.
show-fragment-borders Paint borders along fragment boundaries.
show-parallel-paint Overlay tiles with colors showing which thread painted them.
show-parallel-layout Mark which thread laid each flow out with colors.
paint-flashing Overlay repainted areas with a random color.
trace-layout Write layout trace to an external file for debugging.
validate-display-list-geometry Display an error when display list geometry escapes overflow region.
disable-share-style-cache Disable the style sharing cache.
parallel-display-list-building Build display lists in parallel.
replace-surrogates Replace unpaires surrogates in DOM strings with U+FFFD. See https://github.com/servo/servo/issues/6564
gc-profile Log GC passes and their durations.
$ ./mach run -d -Z blah
error: unrecognized debug option: blah
Servo exited with return value 1
```
Didn't check that setting debug flags actually did anything.
Haven't written much Rust so this feels more verbose than necessary.
Added `disable-canvas-aa` to debug options help.
Should DebugOptions struct derive Clone like Opts does?
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/7165)
<!-- Reviewable:end -->
script: Make the resource task communication use IPC channels.
This change makes Servo use serialized messages over IPC channels for resource loading. The goal is to make it easier to make Servo multiprocess in the future. This patch does not make Servo multiprocess now; there are many other channels that need to be changed to IPC before that can happen. It does introduce a dependency on https://github.com/serde-rs/serde and https://github.com/pcwalton/ipc-channel for the first time.
At the moment, `ipc-channel` uses JSON for serialization. This is because serde does not yet have official support for bincode. When serde gains support for bincode, I'll switch to that. For now, however, the JSON encoding and decoding will constitute a significant performance regression in resource loading.
To avoid having to send boxed `AsyncResponseTarget` trait objects across process boundaries, this series of commits changes `AsyncResponseTarget` to wrap a sender only. It is then the client's responsibility to spawn a thread to proxy calls from that sender to the consumer of the resource data. This only had to be done in a few places. In the future, we may want to collapse those threads into one per process to reduce overhead. (It is impossible to continue to use `AsyncResponseTarget` as a boxed trait object across processes, regardless of how much work is done on `ipc-channel`. Vtables are fundamentally incompatible with IPC across mutually untrusting processes.)
In general, I was pretty pleased with how this turned out. The main changes are adding serialization functionality to various objects that `serde` does not know how to serialize natively—the most complicated being Hyper objects—and reworking `AsyncResponseTarget`. The overall structure of the code is unchanged, and other than `AsyncResponseTarget` no functionality was lost in moving to serialization and IPC.
r? @jdm
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6586)
<!-- Reviewable:end -->
Use local slice_chars
StrExt::slice_chars is deprecated and will be removed in Rust. This
lifts the implementation from Rust libstd and puts it in util::str.
This fixes a bunch of deprecation warnings in Servo.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6876)
<!-- Reviewable:end -->
StrExt::slice_chars is deprecated and will be removed in Rust. This
lifts the implementation from Rust libstd and puts it in util::str.
This fixes a bunch of deprecation warnings in Servo.
`OptionalIpcSender<T>`.
`OptionalIpcSender<T>`dynamically switches between in-process and
out-of-process communication depending on whether multiprocess mode is
enabled.
The multiprocess command-line switch doesn't actually turn on
multiprocess mode yet, but it does control the behavior of
`OptionalIpcSender<T>`.
To actually make the multiprocess communication work, we'll need to
reroute the task creation to the pipeline or the compositor. But this
works as a first step.
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.
Borrow the QueueData for WorkQueue::run.
This allows us to get rid of the raw pointers and unsafe dereferencing in
the parallel layout implementation.
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6547)
<!-- Reviewable:end -->
layout: Disable parallel display list building by default.
I've never see it result in a speedup. Actually, I don't think I've seen
it result in anything better than a 50% slowdown. The arithmetic
intensity is just too low, at least with the current algorithm.
Parallel DL building can still be enabled with a debug flag if the
algorithm is improved.
r? @metajack
<!-- Reviewable:start -->
[<img src="https://reviewable.io/review_button.png" height=40 alt="Review on Reviewable"/>](https://reviewable.io/reviews/servo/servo/6365)
<!-- Reviewable:end -->
