Make manifest updates/html5lib non mandatory
Remove the 'pub use self::BindingDeclarations::*;' export.
Point it to InterfaceTypes.rs directly to export generated types.
auto merge of #2257 : zmike/servo/embedding-base, r=larsbergstrom

Another attempt at the merginating of my long-dormant embedding work for #441

This adds the basics for the embedding crate: build rules and 1800+ lines of CEF types

r? @larsbergstrom
auto merge of #2290 : saneyuki/servo/export, r=jdm

- Fix #2128
- Take over from #2220

I didn't change `InterfaceTypes.rs` to `type.rs` because `type` is very common name which might be troublesome.
Node::GetParentElement should use and_then instead of filtered/map.
auto merge of #2291 : saneyuki/servo/2287, r=jdm

Fix #2287
Update web-platform-tests expectations.

The first 11 tests in Event-constructors.html were fixed in #2194; the
remaining failure is #2173. Node-normalize.html was fixed in #2221.
auto merge of #2294 : Ms2ger/servo/update-wpt, r=jdm

The first 11 tests in Event-constructors.html were fixed in #2194; the
remaining failure is #2173. Node-normalize.html was fixed in #2221.
auto merge of #2258 : Manishearth/servo/wptupdate, r=jdm

Since the manifest is now checked in to the tree, we don't need html5lib unless we want to explicitly update the manifest.

I've added the `--update-manifest` argument to the make target (`export WPTARGS=--update-manifest;make check-wpt`) which triggers the update, installing dependencies if necessary.
Replace Au::zero_* with generic methods
auto merge of #2289 : mbrubeck/servo/zero-geom, r=metajack

Depends on mozilla-servo/rust-geom#33.
layout: Re-enable parallel layout by removing all `RefCell` instances
from `Flow`s; in the process, remove `InlineInfo` in favor of the
range-based design that was originally planned and halfway implemented.

Now, the DOM tree structure for inline flows is reflected not by a
series of arrays but instead by a flat list of ranges into the list of
boxes. As part of this, the `border` and `padding` fields, which were
incorrect in the case of inlines and necessitated separate
`noncontent_inline_foo` methods, have been merged into a single
`border_padding` field that is always guaranteed to be correct after
width assignment, even for inlines.
auto merge of #2174 : pcwalton/servo/reparallelize, r=SimonSapin

layout: Re-enable parallel layout by removing all `RefCell` instances from `Flow`s; in the process, remove `InlineInfo` in favor of the range-based design that was originally planned and halfway implemented.

Now, the DOM tree structure for inline flows is reflected not by a
series of arrays but instead by a flat list of ranges into the list of
boxes. As part of this, the `border` and `padding` fields, which were
incorrect in the case of inlines and necessitated separate
`noncontent_inline_foo` methods, have been merged into a single
`border_padding` field that is always guaranteed to be correct after
width assignment, even for inlines.

r? @SimonSapin and/or @larsbergstrom

Closes #1280 
Closes #1926
Closes #1999 
Closes #2013
Closes #2018
layout: Rewrite display list building to be parallel and to handle
overflow correctly, and opportunistically lay out blocks in parallel
even if floats are present.

This commit fixes the `inline-height-test` in Acid2 by implementing
proper overflow as well as the inline "strut".  (See CSS 2.1 § 10.8.1.)
Acid2 was accidentally being rendered properly before because tables'
descendant flows were not being laid out properly.

Display list building is now parallel and is done by bubbling up display
items and layers from parent to child. Speedups of around 60%-70% are
observed on Wikipedia with a 4-core HyperThreaded Core i7.  More
optimizations are possible; this is just a start.

To minimize the amount of data that needs to be bubbled up, as well as
to make proper handling of `overflow: hidden` clipping easier, the
`StackingContext` abstraction is now purely internal to the display
list.  That is, instead of placing items into a stacking context
directly, display items are placed into display lists alongside a
stacking level.  When a stacking context is complete, it is flattened
with the the `flatten` method, which shuffles the display items that
make up the context into their proper order while handling clipping
properly.
auto merge of #2235 : pcwalton/servo/parallel-floats, r=larsbergstrom

layout: Rewrite display list building to be parallel and to handle
overflow correctly, and opportunistically lay out blocks in parallel
even if floats are present.

This series of commits fixes the `inline-height-test` in Acid2 by
implementing proper overflow as well as the inline "strut". (See CSS 2.1
§ 10.8.1.) It was accidentally working before because tables' descendant
flows were not being laid out properly.

Display list building is now parallel and is done by bubbling up display
items and layers from parent to child. Speedups of around 60%-70% are
observed on Wikipedia with a 4-core HyperThreaded Core i7. More
optimizations are possible; this is just a start.

To minimize the amount of data that needs to be bubbled up, as well as
to make proper handling of `overflow: hidden` clipping easier, the
`StackingContext` abstraction is now purely internal to the display
list. Instead of placing items into a stacking context directly, display
items are placed into display lists with an explicit `StackingLevel`
provided. The stacking level determines a display item's position within
the stacking context. When a stacking context is finished, it is
flattened with the the `flatten` method, which shuffles the display
items that make up the context into their proper order while handling
clipping properly.

r? @SimonSapin and/or @larsbergstrom
layout: Guess the width of block formatting contexts so that we can
speculatively lay them out in parallel
auto merge of #2256 : pcwalton/servo/simple-block-formatting-contexts, r=larsbergstrom

r? @SimonSapin
Webidl and basic implementation of XHR object
auto merge of #2292 : Manishearth/servo/xhr-webidl, r=Ms2ger

This just gets a working interface with dummy methods in place that can  be built on. I'll implement stuff as we go along.

Blocks #2282