This changes the cssparser setup to:
* Avoid having to do copies of the ParsingContext all over the place,
which is useful because I plan to stash more nesting state in there.
* Use the new RuleBodyParser which allows parsing qualified rules,
declarations, and so on. Though we still don't use this anywhere.
The next step is to join NestedRuleParser and PropertyDeclarationParser,
so that we can parse declarations in a lot of the nested rules as well.
Differential Revision: https://phabricator.services.mozilla.com/D178053
This changes the cssparser setup to:
* Avoid having to do copies of the ParsingContext all over the place,
which is useful because I plan to stash more nesting state in there.
* Use the new RuleBodyParser which allows parsing qualified rules,
declarations, and so on. Though we still don't use this anywhere.
The next step is to join NestedRuleParser and PropertyDeclarationParser,
so that we can parse declarations in a lot of the nested rules as well.
Differential Revision: https://phabricator.services.mozilla.com/D178053
No implementation just yet (the default QualifiedRuleParser
implementation just rejects stuff), but this is plumbing that I'd rather
get reviewed separately.
Differential Revision: https://phabricator.services.mozilla.com/D176686
Using the newer version of the crash-context crate corrects the 32-bit Linux context structure,
which was the cause of the IP memory not being stored (among possibly other 32-bit Linux issues).
Differential Revision: https://phabricator.services.mozilla.com/D174314
Make use of the new changes in the cssparser that allows 'none' keywords
in color components where allowed. We store the none values as 0.0 (as
per the spec) and mark the components with the flags. This way we don't
have to check anything on the components before doing calculations.
As this is the last part intended to be released for the new [color-4]
changes, I've also enabled the changes on nightly.
Differential Revision: https://phabricator.services.mozilla.com/D170208
Make use of the new changes in the cssparser that allows 'none' keywords
in color components where allowed. We store the none values as 0.0 (as
per the spec) and mark the components with the flags. This way we don't
have to check anything on the components before doing calculations.
As this is the last part intended to be released for the new [color-4]
changes, I've also enabled the changes on nightly.
Differential Revision: https://phabricator.services.mozilla.com/D170208
Make use of the new changes in the cssparser that allows 'none' keywords
in color components where allowed. We store the none values as 0.0 (as
per the spec) and mark the components with the flags. This way we don't
have to check anything on the components before doing calculations.
As this is the last part intended to be released for the new [color-4]
changes, I've also enabled the changes on nightly.
Differential Revision: https://phabricator.services.mozilla.com/D170208
Make use of the new changes in the cssparser that allows 'none' keywords
in color components where allowed. We store the none values as 0.0 (as
per the spec) and mark the components with the flags. This way we don't
have to check anything on the components before doing calculations.
As this is the last part intended to be released for the new [color-4]
changes, I've also enabled the changes on nightly.
Differential Revision: https://phabricator.services.mozilla.com/D170208
In stead of having the css parser construct a color in it's own format
and then converting it to what Gecko needs to perform operations, we now
construct a Gecko friendly color type directly.
Differential Revision: https://phabricator.services.mozilla.com/D170187
Use new changes from cssparser and use the new lab/lch/oklab/oklch color
formats.
Introduced a new color type AbsoluteColor. It represents any kind of
color that has absolute numerical values. It is also tied to a color
space and therefore can be trivially converted to another color space.
Differential Revision: https://phabricator.services.mozilla.com/D163579
Use new changes from cssparser and use the new lab/lch/oklab/oklch color
formats.
Introduced a new color type AbsoluteColor. It represents any kind of
color that has absolute numerical values. It is also tied to a color
space and therefore can be trivially converted to another color space.
Differential Revision: https://phabricator.services.mozilla.com/D163579
This brings in various bugfixes and improvements from upstream,
including the fix for bug 1791809 and a workaround for bug 1804530.
In this update, `wgpu_core` leaves the selection of backends to its
users, rather than trying to guess which backends to use itself, based
on the target architecture and operating system. For Firefox, this
means that `gfx/wgpu_bindings/Cargo.toml` is now responsible for
selecting back ends.
Firefox's WebGPU implementation should never use `wgpu`'s GLES
backend. Firefox can now explain this to `wgpu-core`, causing it to
drop its dependency on `glow`, `bitflags_serde_shim` and `slotmap`.
These are no longer vendored, and their exemptions in
`supply-chain/config.toml` can be dropped.
The new `wgpu-core` updates to version 0.37.1+1.3.235 of the `ash`
crate, and this patch moves ash's supply-chain exemption forward to
the new version. We expect to finish vetting that next week, but
because this `wgpu-core` update is urgently needed, we want to extend
the exemption for the time being.
The dependency on `slotmap` had been patched to an empty file in
`build/rust/dummy-web`, which can now be removed.
The new `wgpu-core` no longer uses `cfg_aliases`, so Firefox no longer
needs to vendor that.
Differential Revision: https://phabricator.services.mozilla.com/D164928
Cargo will attempt to build all targets for dependencies, and there
appears to be no option to turn that functionality off (see
https://github.com/rust-lang/cargo/issues/11232). If we try to build the
`rure` crate as a cdylib during a PGO build, it causes linker issues,
which make the build fail. As this artifact isn't necessary for our
build, we can patch the crate to remove the cdylib and staticlib
crate-type definitions, making the build pass as only the artifact we
need is built.
Differential Revision: https://phabricator.services.mozilla.com/D159332
- Added `--enable-uniffi-fixtures` flag. When set, we will compile in
the UniFFI test fixtures into our shared Rust crate and eventually
into `libxul`.
- Vendoring in the Rust crates needed for `uniffi-bindgen-gecko-js`
Differential Revision: https://phabricator.services.mozilla.com/D144467
Generate the C++ and JS code to handle UniFFI bindings. The WebIDL code
is completely static and doesn't need to be generated.
There's support for both synchronus and async functions, but we haven't
decided the how we want this to be configured. In practice, almost all
functions will need to be async, so for now we're just forcing all
functions to be.
The `uniffi-bindgen-gecko-js` crate builds the binary that generates the
bindings. This binary needs to be fed a list of UDL files, the path of
the .cpp file to generate, and the directory to generate .jsm files in
(and also all of those arguments again, but for the test fixtures).
This is quiet a horrible UI, but it's going to be wrapped in a mach
command.
The `uniffi-js` directory contains shared C++ code for
`uniffi-bindgen-gecko-js`. As much as possible we tried to put the
functionality here and have the generated code simply forward function
calls here.
Still Todo:
- CallbackInterfaces
- Custom and external types
- Datetime and TimeInterval
Differential Revision: https://phabricator.services.mozilla.com/D144472
- Added `--enable-uniffi-fixtures` flag. When set, we will compile in
the UniFFI test fixtures into our shared Rust crate and eventually
into `libxul`.
- Vendoring in the Rust crates needed for `uniffi-bindgen-gecko-js`
Differential Revision: https://phabricator.services.mozilla.com/D144467
Generate the C++ and JS code to handle UniFFI bindings. The WebIDL code
is completely static and doesn't need to be generated.
There's support for both synchronus and async functions, but we haven't
decided the how we want this to be configured. In practice, almost all
functions will need to be async, so for now we're just forcing all
functions to be.
The `uniffi-bindgen-gecko-js` crate builds the binary that generates the
bindings. This binary needs to be fed a list of UDL files, the path of
the .cpp file to generate, and the directory to generate .jsm files in
(and also all of those arguments again, but for the test fixtures).
This is quiet a horrible UI, but it's going to be wrapped in a mach
command.
The `uniffi-js` directory contains shared C++ code for
`uniffi-bindgen-gecko-js`. As much as possible we tried to put the
functionality here and have the generated code simply forward function
calls here.
Still Todo:
- CallbackInterfaces
- Custom and external types
- Datetime and TimeInterval
Differential Revision: https://phabricator.services.mozilla.com/D144472
- Added `--enable-uniffi-fixtures` flag. When set, we will compile in
the UniFFI test fixtures into our shared Rust crate and eventually
into `libxul`.
- Vendoring in the Rust crates needed for `uniffi-bindgen-gecko-js`
Differential Revision: https://phabricator.services.mozilla.com/D144467
Generate the C++ and JS code to handle UniFFI bindings. The WebIDL code
is completely static and doesn't need to be generated.
There's support for both synchronus and async functions, but we haven't
decided the how we want this to be configured. In practice, almost all
functions will need to be async, so for now we're just forcing all
functions to be.
The `uniffi-bindgen-gecko-js` crate builds the binary that generates the
bindings. This binary needs to be fed a list of UDL files, the path of
the .cpp file to generate, and the directory to generate .jsm files in
(and also all of those arguments again, but for the test fixtures).
This is quiet a horrible UI, but it's going to be wrapped in a mach
command.
The `uniffi-js` directory contains shared C++ code for
`uniffi-bindgen-gecko-js`. As much as possible we tried to put the
functionality here and have the generated code simply forward function
calls here.
Still Todo:
- CallbackInterfaces
- Custom and external types
- Datetime and TimeInterval
Differential Revision: https://phabricator.services.mozilla.com/D144472
The baldrdash integration of Cranelift is agreed between SM and CL
to be the wrong shape. Our import of the code base is also old and
causes difficulties for us when upgrading some crates (see bug
1774829). We should remove it for now to unblock bug 1774829.
Differential Revision: https://phabricator.services.mozilla.com/D152806
Some crates in our graph have dependencies on parking_lot >= 0.11,
<=0.12, meaning `cargo update` might pull parking_lot 0.12, which brings
windows-sys.
mio >= 0.8.1 also pulls windows-sys in.
Differential Revision: https://phabricator.services.mozilla.com/D148587
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
Upgrades to Glean v50.0.1, which comes with a rewritten core and
UniFFI-powered bindings.
Glean has some API changes, so we swap it over to that. Mostly mechanical changes.
Also upgrades to inherent v1.0 in fog.
This matches what Glean uses internally and gets rid of one duplicated crate.
Also upgrades to glean-parser==6.0.1
One crate duplication now (change in `python/mozbuild/mozbuild/vendor/vendor_rust.py` required).
Some new crates now vendored.
These are transitive dependencies of Glean dependencies, all with valid
licenses and already used in other products (mobile).
Differential Revision: https://phabricator.services.mozilla.com/D146062
This patch imports and implements all the infrastructure for origin
trial tokens, minus the crypto stuff / token verification.
We still don't hook it anywhere. The intended setup for now would be to
have the `OriginTrials` object hanging off the `Document` (or global
perhaps, not sure yet). That has a self-descriptive API to enable trials
(UpdateFromToken), and check enabledness status (IsEnabled).
There are some tests in the origin-trial-token crate
(third_party/rust/origin-trial-token/tests.rs). No test for the DOM code
yet because this isn't hooked into yet.
Differential Revision: https://phabricator.services.mozilla.com/D139033
The midir update reduces the differences with upstream to the coremidi
version.
And now the coremidi override is done via a patch at the top-level. The
revision we were using is gone, but it turns out the new master is
identical in content (at least, as far as vendoring is concerned).
Differential Revision: https://phabricator.services.mozilla.com/D135194
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Depends on D130820
Differential Revision: https://phabricator.services.mozilla.com/D122392
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
Apart from Cargo.toml being garbled by cargo on publication, what's
vendored is exactly the same as on crates.io, so we don't need to use a
patch to pull from git anymore.
Differential Revision: https://phabricator.services.mozilla.com/D133040
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
This patch introduces ipcclientcerts, a PKCS#11 module that the socket process
can load to get access to client certificates and keys managed by the parent
process. This enables client certificate authentication to work with the socket
process (particularly for keys stored outside of NSS, as with osclientcerts or
third-party PKCS#11 modules).
Differential Revision: https://phabricator.services.mozilla.com/D122392
This update makes wgpu a vendored dependency instead of having it in gfx/wgpu.
## Notes
It relies on https://phabricator.services.mozilla.com/D123157
It has a quirk related to OpenGL ES backend. Previousy, we manually had to disable GL backend
in order to avoid vendoring WASM dependencies in. This time, manual editing is more complicated,
so instead this change adds a few cargo patch lines to point WASM dependencies to dummy projects.
The update also totally removes SPIRV-Cross, since the latest `wgpu` doesn't depend on it any more.
The compiled binary size for Gecko should improve with this.
Differential Revision: https://phabricator.services.mozilla.com/D123153
This patch bumps the minidump_writer_linux crate but does not import any new
changes, the only difference is that it now depends on nix 0.15
Differential Revision: https://phabricator.services.mozilla.com/D124175
crossbeam-channel to v0.5.1
crossbeam-deque to v0.7.3
crossbeam-epoch to v0.8.2
crossbeam-utils to v0.6.6, v0.7.2, and v0.8.5
autocfg 0.1.6 ends up removed because nothing uses it anymore.
Differential Revision: https://phabricator.services.mozilla.com/D117750
This patch tries to address the issue that legacy CJK extensions have various
extended variants where the core of the encoding is compatible but the edges
are incompatible. Without this patch, we reject e.g. Big5 if it has a single
character from the UAO extension or a single Windows end-user-defined character.
Likewise for the other legacy CJK encodings.
This patch tolerates:
* All Big5 extensions (the motivating part of this patch).
* Windows EUDC for EUC-KR.
* Classic Mac OS extensions to Shift_JIS, EUC-KR, GBK, and Big5 to the
extent practical considering conflicting definitions of what constitutes
a lead byte in the Encoding Standard but a single-byte extension in
Classic Mac OS.
* JIS X 0213 / 2004 extensions to Shift_JIS and EUC-JP. (It's unclear if
these have actual deployment.)
Tolerating means that the occurrence of an extension character doesn't
disqualify a candidate but only applies a penalty to the pending score.
If there is enough other convincing content, it should be able to overcome
the penalty.
Differential Revision: https://phabricator.services.mozilla.com/D111372
This is a minimal implementation of a WER exception module that can intercept
crashes of Firefox processes and write out a fully formed crash report, that is
a minidump, an .extra file containing the minimum annotations required by
Socorro and an event file.
The module in and by itself is not functional: an entry needs to be added to
the registry and the processes which want to be monitored need to register it
at runtime. With this patch applied it will only be built but it won't be
packaged with Firefox nor it will be used when doing local development.
The module implementation has a few notable properties:
* We use an empty C++ shim (mozwer) to build the module DLL. This is
because the build system doesn't support building DLLs directly from Rust.
* The actual implementation is written in Rust (mozwer-rust) and exposes the
callbacks that will be invoked by the WER service.
* We use the winapi crate to access Windows native functionality but given it
is missing some bits (including upstream!) we declare them in our crate for
the time being.
* The minidump uses the same options we use in Firefox and should be of
similar size. I manually tested different type of crashes including
__fastail() ones and they're all reliably captured.
* The .extra file contains only the annotations that are strictly required for
submitting the crash to crash-stats.mozilla.org. More should be added in the
future. The existing annotations are all extracted from within the module
code because we have no way to access the ones that were stored in Firefox'
crashed processes (nor should we, since we hope to catch crashes that happen
even before Firefox sets up crash reporting internally).
* The module does not distinguish between main process and content process
crashes at the moment. This will need to be implemented when we hook it up
with the crash reporting code within Firefox.
* We use libc's time() function to get the crash time in order to be consistent
with what the regular exception handler does.
Differential Revision: https://phabricator.services.mozilla.com/D101708
The logic missed a pair of brackets, leading to memory regions
being merged that shouldn't have been merged (anonymous regions
with access flags set getting merged into the previous mapping)
Differential Revision: https://phabricator.services.mozilla.com/D106772
This is another WebGPU API update, it picks up a lot of changes that were made recently:
- new bind group layout
- new render pipeline descriptor
- new vertex formats
- limits
- compressed texture formats
- index format
- query sets
- and more small ones!
It also brings in the updated `gfx/wgpu` to support these API changes.
Differential Revision: https://phabricator.services.mozilla.com/D107013
This is another WebGPU API update, it picks up a lot of changes that were made recently:
- new bind group layout
- new render pipeline descriptor
- new vertex formats
- limits
- compressed texture formats
- index format
- query sets
- and more small ones!
It also brings in the updated `gfx/wgpu` to support these API changes.
Differential Revision: https://phabricator.services.mozilla.com/D107013
The mozjs_sys crate is actually responsible for all the problems
encountered with the js crate we just removed, but the sm-mozjs-crate
task that builds and runs tests for it doesn't fail because... there is
actually no test to build and run, so all it builds is a static library,
which doesn't expose all the problems that exist.
The content of this crate in mozilla-central is also outdated compared
to servo upstream.
Differential Revision: https://phabricator.services.mozilla.com/D106390
The sm-rust-bindings task that builds and runs tests for it actually only
doesn't fail by three(!) distinct happenstances of chance:
- It somehow doesn't hit a race condition that can happen, but that
attempting to change the build process for jsglue.cpp did,
- The second call to `cargo test` without `--feature debugmozjs` only
works because nothing was cleaned up from the first and the second
build uses artifacts from the first that are otherwise not there if
only running the second.
- The addition of rust code to spidermonkey (the jsrust crate in
js/src/rust) somehow didsn't cause problems in the current
configuration, but in other configurations (which fixing the second
thing above unveils) the build fails because of the multiple
definition of rust_eh_personality between the jsrust staticlib and the
rust stdlib that rustc links to test programs.
On top of all the above, the content of the crate in mozilla-central
has not received updates from upstream servo in years, and doesn't
reflect what servo actually uses.
Differential Revision: https://phabricator.services.mozilla.com/D106389
Now that we use an external dump_syms, we don't need to build
breakpad's.
This means we also don't need the dump_syms_rust_demangle crate anymore.
Differential Revision: https://phabricator.services.mozilla.com/D101865
Fixes errors like:
dependency (nix) specification is ambiguous. Only one of `branch`, `tag` or `rev` is allowed.
I've left the most specific dependency, but for wgpu the rev is not
right, so I've kept the branch which effectively preserves behavior.
Differential Revision: https://phabricator.services.mozilla.com/D100485
I'm keeping the --enable-update-agent config option and the corresponding
MOZ_UPDATE_AGENT config flag and define, as these should still be useful.
As we never shipped this there is no need to keep anything around to
clean up the scheduled tasks.
Differential Revision: https://phabricator.services.mozilla.com/D99574
Instantiating a wasm library duplicates a file descriptor for /dev/null 3 times to be used as input, output and error streams for the wasm sandboxed code. When a lot of sandboxes are created and destroyed, a lot of descriptors are duplicated and closed. While this should be fine, POSIX does not seem to happy with the opening and closing of many file descriptors --- this could perhaps be some strange interaction with Firefox's seccomp filters and cross-process file descriptor handling as it is difficult to repro this outside of firefox.
However, the simpler fix here was to just eliminate the duplication of /dev/null and return an error when input, output or error streams are accessed by wasm sandboxed code. This means calls to printf will fail, but no code I know off actually checks the int error code returned by printf and this change is certainly compatible with existing sandboxed components.
Differential Revision: https://phabricator.services.mozilla.com/D99160
Revendor Cranelift to 3b01b4b850bafb981a04383198c0b50d041dc5ef
from https://github.com/mozilla-spidermonkey/wasmtime branch firefox85.
The (only) purpose is to pull in this:
commit 31bac3eafbfda8f1ffb504cdeb75505d48537336
Merge: 93c199363 34d9931ed
Author: Nick Fitzgerald <fitzgen@gmail.com>
Date: Wed Nov 25 13:09:05 2020 -0800
Merge pull request #2450 from bytecodealliance/cfallin/fix-wasm-reachable
Fix Wasm translator bug: end of toplevel frame is branched-to only for fallthrough returns.
Differential Revision: https://phabricator.services.mozilla.com/D99204
On a very parallel debug build, I see a long time just waiting for
bindgen / style compilation / geckoservo.
Turns out that a bunch of this is just proc macros / build scripts.
Optimizing it saves between 10 and 17 seconds of my debug build. We
might want to consider running bindgen much like cbindgen rather than
rebuilding it all the time, which should help a lot more, but my guess
is that this should still help with the pretty hot custom derives that
the style crate runs.
This needs rust 1.41, so the requirement for tools/crashreporter needs
to be bumped as a consequence. To make things simpler, it was bumped
to 1.47 while we're at it.
Differential Revision: https://phabricator.services.mozilla.com/D98366
Butkovits Atila
Tiaan Louw
Emilio Cobos Álvarez
Natalia Csoregi
Bobby Holley
Sandor Molnar
John Schanck
Mike Hommey
Alex Franchuk
Matthew Gregan
Mark Hammond
Marian-Vasile Laza
Cristina Horotan
Sammy Khamis
Ryan VanderMeulen
Nika Layzell
Jan-Erik Rediger
Mike Hommey
Norisz Fay
zaggy1024
Chris H-C
Cosmin Sabou
Gabriele Svelto
Jim Blandy
Noemi Erli
Cristian Tuns
pmcmanis
Dragana Damjanovic
Ben Dean-Kawamura
criss
Ryan Hunt
Travis Long
Bogdan Szekely
Sebastian Hengst
Jan-Erik Rediger
M. Sirringhaus
Bas Schouten
Henri Sivonen
Dana Keeler
Andreea Pavel
Dzmitry Malyshau
Deian Stefan
Yury Delendik
Jeff Muizelaar
Brindusan Cristian
Julian Seward
Razvan Maries
Adam Gashlin
shravanrn@gmail.com