Update:
- Glean to v53.1.0
- UniFFI to v0.24.1
- application-services to a recent nightly that uses the above
versions
- Updated `rusqlite` in toolkit/library/rust/shared/Cargo.toml
- Updated `uniffi-bindgen-gecko-js` to work with the new UniFFI. Also
updated it's askama version.
- Vetted new cargo dependencies
Ran `mach uniffi generate` to regenerate the code.
Differential Revision: https://phabricator.services.mozilla.com/D181872
Update:
- Glean to v53.1.0
- UniFFI to v0.24.1
- application-services to a recent nightly that uses the above
versions
- Updated `rusqlite` in toolkit/library/rust/shared/Cargo.toml
- Updated `uniffi-bindgen-gecko-js` to work with the new UniFFI. Also
updated it's askama version.
- Vetted new cargo dependencies
Ran `mach uniffi generate` to regenerate the code.
Differential Revision: https://phabricator.services.mozilla.com/D181872
This adds a crate that override's the windows-targets crate to avoid
depending on the large import libraries in its dependencies.
Differential Revision: https://phabricator.services.mozilla.com/D183824
First, instead of using a path, use a version, which is more convenient
(via a patch in the top-level Cargo.toml).
Second, we make the build system itself enforce its presence for any
crate that is hooked to the build system as a program or library.
Finally, for each crate depending on the workspace hack, we add a
feature named after it, and make the build system enforce that the
feature is set. For now, this remains unused, but the end goal is to
have each of those features enable the dependencies each of these
crates need, so that if crate A and B need dependency D, but crate C
doesn't, building crate C doesn't build D.
Differential Revision: https://phabricator.services.mozilla.com/D180910
In practice, the result looks better than with clap's wrap_help
disabled, and, as a matter of personal preference, looks better to
me than when using the actual terminal size.
This will allow to upgrade clap to a more recent version without
pulling in windows-sys.
Differential Revision: https://phabricator.services.mozilla.com/D179748
It's only used by glean in code that is not actually used. It allows to
remove the only use of dashmap, which is a rather complex crate.
Differential Revision: https://phabricator.services.mozilla.com/D179747
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