I moved away from the `Window` struct all the logic to handle task
sources, into a new struct called `TaskManager`. In a happy world, I'd
be able to just have there two functions, of the types:
```rust
fn task_source<T: TaskSource>(&self, name: TaskSourceName) -> Box<T>
fn task_source_with_canceller<T: TaskSource>(&self, name: TaskSourceName)
-> (Box<T>, TaskSourceCanceller)
```
And not so much duplicated code. However, because TaskSource can't be a
trait object (because it has generic type parameters), that's not
possible. Instead, I decided to reduce duplicated logic through macros.
For reasons[1], I have to pass both the name of the function with
canceller and the name of the function without, as I'm not able to
concatenate them in the macro itself. I could probably use
`concat_idents` to create both types already defined and reduce the
amount of arguments by one, but that macro is nightly only. At the same
time, not being able to declare macros inside `impl` forces me to pass
`self` as an argument.
All this makes this solution more verbose than it would be ideally. It
does reduce duplication, but it doesn't reduce the size of the file.
[1](https://github.com/rust-lang/rust/issues/29599)
Fixes warnings from rust-lang/rust#44229 when `--enable-commonmark` is
passed to rustdoc.
This is mostly a global find-and-replace for bare URIs on lines by
themselves in doc comments.
http://www.robohornet.org gives a score of 101.36 on master,
and 102.68 with this PR. The latter is slightly better,
but probably within noise level.
So it looks like this PR does not affect DOM performance.
This is expected since `Box::new` is defined as:
```rust
impl<T> Box<T> {
#[inline(always)]
pub fn new(x: T) -> Box<T> {
box x
}
}
```
With inlining, it should compile to the same as box syntax.
In a later PR, DomRoot<T> will become a type alias of Root<Dom<T>>,
where Root<T> will be able to handle all the things that need to be
rooted that have a stable traceable address that doesn't move for the
whole lifetime of the root. Stay tuned.
Consistently use the name 'pipeline_id' to refer to a function that
returns an (optional) PipelineId.
This was prompted by discovering both fn pipeline and fn pipeline_id
doing the same job in htmliframeelement.rs.
Note that there is fn pipeline in components/compositing/compositor.rs,
but that actually returns an Option<&CompositionPipeline>, not any kind
of PipelineId.
Changes include:
- Introduce an IpcSend trait to abstract over a collection of IpcSenders
- Implement ResourceThreads collection to abstract the resource-related
sub threads across the component
- Rename original ResourceThread and ControlMsg into an unifed CoreResource__
to accommodate above changes and avoid confusions
