Minor change, added unit test filter to components so that ./mach test-unit [test-filter] works in line with documentation.
I'd personally like to also make filters on the components as well as the tests. This would change the interface (probably to ./mach test-unit [component-filter] [test-filter]), but change is NOT in this pull request.
This patch is a first stab at implementing border-radius. It looks fine as long as
the border isn't an ellipse (that might not even parse yet), and the border-widths
around a border-radius are the same.
Here's a cool screenshot!
r? @pcwalton @SimonSapin
This patch is a first stab at implementing border-radius. It looks fine as long as
the border isn't an ellipse (that might not even parse yet), and the border-widths
around a border-radius are the same.
Here's a cool screenshot!
r? @pcwalton @SimonSapin
Moved all getters from Element to ElementHelpers. Existing ElementHelpers getters `get_namespace` and `get_local_name` were replaced by `namespace` and `local_name`. Callers were updated accordingly. Also the getters are no longer inlined.
3 of the getters needed to be added to RawLayoutElementHelpers as well, to accomodate existing calls directly from Element objects.
`./mach test-ref` no longer eats the first "-" prefixed argument for test name filtering, instead using an explicit "--name" argument. This should avoid any potential confusion when passing down arguments to servo.
Also allows for ./tests/ref to be included (and trimmed away) for tab completion convenience (`./mach test` has also been updated to take advantage of this when inferring tests from file paths).
(fixes#4091)
- Added TargetedLoadResponse and ResponseSenders
- LoadData constructor contains the next consumer which means
SnifferManager doesn't need the next consumer to start
- New SnifferTask is created at new resource_task creation
- Update Unit Tests
This replaces hand-implemented CEF bindings with proper Rust wrappers
automatically generated from the C++ headers. This means that, whenever
CEF's C++ headers change, we can easily generate both the appropriate C
API and the appropriate Rust API. It eliminates much of the hand-written
unsafe code within the CEF port, because the CEF translator tool now
knows how to generate Rust smart pointer wrappers for each class that
corrently perform reference counting.
Additionally, this commit adds utility macros (located in `macros.rs`)
that make it easier to correctly expose Rust objects as CEF objects.
They handle the marshaling of objects between Rust and CEF properly.
The net result of this is that you can write mostly-natural-looking Rust
in the CEF port and interact with it with a natural-looking C++ API on
the embedding side.
This setup relies on the branch of CEF located here:
https://github.com/pcwalton/chromium-embedded-framework
To regenerate, follow the instructions in `ports/cef/README.md`. For
convenience, and because I don't anticipate the API to change much, I
have vendored in all of the appropriate interfaces.
r? @zmike or @larsbergstrom
bindings.
This replaces hand-implemented CEF bindings with proper Rust wrappers
automatically generated from the C++ headers. This means that, whenever
CEF's C++ headers change, we can easily generate both the appropriate C
API and the appropriate Rust API. It eliminates much of the hand-written
unsafe code within the CEF port, because the CEF translator tool now
knows how to generate Rust smart pointer wrappers for each class that
corrently perform reference counting.
Additionally, this commit adds utility macros (located in `macros.rs`)
that make it easier to correctly expose Rust objects as CEF objects.
They handle the marshaling of objects between Rust and CEF properly.
The net result of this is that you can write mostly-natural-looking Rust
in the CEF port and interact with it with a natural-looking C++ API on
the embedding side.
This setup relies on the branch of CEF located here:
https://github.com/pcwalton/chromium-embedded-framework
To regenerate, follow the instructions in `ports/cef/README.md`. For
convenience, and because I don't anticipate the API to change much, I
have vendored in all of the appropriate interfaces.
