This includes updates to authenticator, cubeb-coreaudio,
metal, gfx-backend-vulkan, gfx-backend-metal, freetype
libloading is duplicated because of ash
Differential Revision: https://phabricator.services.mozilla.com/D84688
A small xpcom module implemented in Rust, designed to provide low-level tools to deal with processes
from JS. For the moment, the only notable feature is `kill()`, designed to be used from about:processes
Differential Revision: https://phabricator.services.mozilla.com/D82552
This lays out a Rust crate and statically links it into
`windows-default-agent.exe`. It declares a single-method API (which
will be invoked in the next commit).
Strings cross the C/C++ <-> Rust FFI boundary as null-terminated
UTF-8. (This will matter more if and when we use ETag and
If-None-Match to get 304 results.)
Errors are reported as Windows result codes, with the "customer" bit
set to encode certain classes of failure.
The bulk of the work is in implementing a
[Viaduct](https://github.com/mozilla/application-services/tree/master/components/viaduct)
backend built on top of `wininet.dll`. The motivation is that if and
when this Remote Settings Rust client grows features (say,
Content-Signature: verification), then by using Viaduct there is a
smooth path to consume the client inside Firefox itself, because
Viaduct already has a backend on top of Necko. That makes this
abstraction relatively low friction: it exists, is in-tree already,
and has a path to use in Gecko proper.
It is expected that the layer above this will handle "gracefully
failing", either open or closed; and will mirror Remote Settings
configuration to the registry so that testers can use prod/stage/dev
easily.
For follow-up:
- Configure logging to use the Windows event logger. See [Bug
1648617](https://bugzilla.mozilla.org/show_bug.cgi?id=1648617).
- Consider propagating errors into the Telemetry we send.
Differential Revision: https://phabricator.services.mozilla.com/D78579
This patch pulls in revision 1b3b2dbfd00492161032760992a8699d19b640ca of
Cranelift. This includes PR bytecodealliance/wasmtime#2042, which fixes
bug 1653502 by properly masking the shift amount in a shift incorporated
into an aarch64 arithmetic instruction.
This patch also includes various other miscellaneous Cranelift
improvements that have been merged since the last version-bump,
including some aarch64 codegen improvements.
Differential Revision: https://phabricator.services.mozilla.com/D84101
This patch updates the vendored version of Cranelift, pulling in the
reference-types support recently merged in Cranelift's PR
bytecodealliance/wasmtime#1852. Usage of this update to support reftypes
in SpiderMonkey on aarch64 is added in the subsequent commit.
Differential Revision: https://phabricator.services.mozilla.com/D83582
On some Adreno 505 and 506 devices we are encountering driver crashes during
glLinkProgram(). The only circumstance in which we have been able to reproduce
locally is when the show-overdraw debug option is enabled. The reason appears to
be that, due to shader optimisation, the debug overdraw variants of many shaders
have identical source code. The crash seems to occur when linking a shader which
has identical source code to a previously linked shader.
This does not, however, explain the non-insignificant numbers of crashes in the
wild because a) it's unlikely many users are enabling overdraw debugging, and b)
some crash reports predate the commit which enabled shader
optimisation. However, it is possible that for a different reason we are
compiling multiple shaders with identical source code.
To attempt to work around this crash this change adds a random comment to the
end of each shader source string, on the affected devices.
Differential Revision: https://phabricator.services.mozilla.com/D83571
On some Adreno 505 and 506 devices we are encountering driver crashes during
glLinkProgram(). The only circumstance in which we have been able to reproduce
locally is when the show-overdraw debug option is enabled. The reason appears to
be that, due to shader optimisation, the debug overdraw variants of many shaders
have identical source code. The crash seems to occur when linking a shader which
has identical source code to a previously linked shader.
This does not, however, explain the non-insignificant numbers of crashes in the
wild because a) it's unlikely many users are enabling overdraw debugging, and b)
some crash reports predate the commit which enabled shader
optimisation. However, it is possible that for a different reason we are
compiling multiple shaders with identical source code.
To attempt to work around this crash this change adds a random comment to the
end of each shader source string, on the affected devices.
Differential Revision: https://phabricator.services.mozilla.com/D83571
This patch pulls in Cranelift revision
47a218f908e6bdeb7a0fb65ed74e58a0b608080d, which incorporates several
relevant changes:
- It includes the Spectre mitigation for explicit heap bounds checks
merged in PR bytecodealliance/wasmtime#1930, resolving Bug 1648885.
- It includes the fix for an out-of-bounds subtraction on large shift
amounts merged in PR bytecodealliance/wasmtime#1954, resolving Bug
1649432.
We need to temporarily disable the `wasm/limits.js` jit-test on
Cranelift configurations because it now needs shared memory to work, and
the Cranelift backend does not support this yet. Given that this should
be ready in the next month at most (requires atomics support on AArch64,
which is currently being examined), it seems simpler to temporarily
disable the test on aarch64 than to try to disentangle the bits that
depend on shared memories explicitly.
This patch also edits the `regexp/bug1445907.js` jit-test to run only if
Wasm debugging is supported. This is needed for the test not to fail
with `--wasm-compiler=cranelift` (which disables Baseline, the only Wasm
compiler that supports debugging).
Differential Revision: https://phabricator.services.mozilla.com/D81936
We were storing LogModule::mName as an &'static str in the map... That's
not fine.
The Arc shenanigans were also more complicated than they need to be IMO.
This uses a plain atomic bool to keep the fast path snappy.
Differential Revision: https://phabricator.services.mozilla.com/D81007
Introduces a gkrust Cargo feature `glean_with_gecko` and `with_gecko` on fog
and glean. This feature signifies the presence of gecko symbols in the build.
Use this feature to implement needs_ipc() which asks Gecko which process type
we're running as.
Differential Revision: https://phabricator.services.mozilla.com/D79744
Introduces a gkrust Cargo feature `glean_with_gecko` and `with_gecko` on fog
and glean. This feature signifies the presence of gecko symbols in the build.
Use this feature to implement needs_ipc() which asks Gecko which process type
we're running as.
Differential Revision: https://phabricator.services.mozilla.com/D79744
This change attempts to parse the incoming SPIR-V shader modules with
Naga SPIR-V front-end. It's not complete, but it returns an Error if it's unable to parse,
in which case we just continue without the validation (for now).
If it succeeds, we extract the reflection information from it, and use it for the pipeline.
This is just a start. More states would need to be validated, and SPIR-V front-end needs more work.
Differential Revision: https://phabricator.services.mozilla.com/D77170
To get this fix: https://github.com/mozilla/application-services/pull/3235
Updated as follows:
```
sed -i 's/e8d7530319fa6c20d9de78d031c9398630eca3cd/61dcc364ac0d6d0816ab88a494bbf20d824b009b/g' services/fxaccounts/rust-bridge/firefox-accounts-bridge/Cargo.toml services/sync/golden_gate/Cargo.toml toolkit/components/extensions/storage/webext_storage_bridge/Cargo.toml toolkit/components/glean/Cargo.toml toolkit/library/rust/shared/Cargo.toml
./mach vendor rust
```
Verified by running the new regression test that I added in the bug:
```
./mach test toolkit/components/extensions/test/xpcshell/test_ext_storage_{local,sync,sync_kinto}.js
```
Differential Revision: https://phabricator.services.mozilla.com/D79628
This is the logic of tracing the WebGPU API calls at the level of wgpu-core,
serialized into a folder of choosing on the user drive. Traces are extremely portable,
they can be shared (on BugZilla) and then replayed on the developer machine,
which can have a different architecture from the users machine.
The standalone player is introduced in `gfx/wgpu/player`, similar to WebRender's Wrench.
The output dir is controlled by "dom.webgpu.traceDir" pref. No tracing happens if it's empty.
Differential Revision: https://phabricator.services.mozilla.com/D73333
This is the logic of tracing the WebGPU API calls at the level of wgpu-core,
serialized into a folder of choosing on the user drive. Traces are extremely portable,
they can be shared (on BugZilla) and then replayed on the developer machine,
which can have a different architecture from the users machine.
The standalone player is introduced in `gfx/wgpu/player`, similar to WebRender's Wrench.
The output dir is controlled by "dom.webgpu.traceDir" pref. No tracing happens if it's empty.
Differential Revision: https://phabricator.services.mozilla.com/D73333
TSan returns false positives for `lazy_static`. While we could
blocklist it, `once_cell` has equivalent functionality, but with a more
modern API, so let's use it instead.
Depends on D75864
Differential Revision: https://phabricator.services.mozilla.com/D76342
This function ought to be declared by `winapi`, but is not, for whatever
reason. However, its definition is stable enough that we can just
declare it inline rather than invoking bindgen every single build (and
unnecessarily compiling a build script on non-windows platforms) to
discover its definition for us.
Differential Revision: https://phabricator.services.mozilla.com/D76015
The upgrade of mp4parse pulled some code that previously was eliminated as
dead code in libxul. That code was unfortunately unreproducible as it
was generating a random seed at compile time. This was due to hashbrown
enabling the ahash feature that does that, but that was changed in 0.7.2.
Differential Revision: https://phabricator.services.mozilla.com/D75033
* Avoid misdetecting windows-1252 English as windows-1254.
* Avoid misdetecting windows-1252 English as IBM866.
* Avoid misdetecting windows-1252 English as GBK or EUC-KR.
* Improve Chinese and Japanese detection by not giving single-byte encodings score for letter next to digit.
* Improve Italian, Portuguese, Castilian, Catalan, and Galician detection by taking into account ordinal indicator use.
* Reduce lookup table size.
Differential Revision: https://phabricator.services.mozilla.com/D73237
This requires --build-peers-said-large-imports-were-ok since
third_party/rust/mp4parse/src/lib.rs is 113KB. This code is just moving from
media/mp4parse-rust to third_party/rust, so it's not really adding to net code
size.
Differential Revision: https://phabricator.services.mozilla.com/D74488
When building in some configurations of rustc (e.g. i386 without SSE), building Firefox fails with, among other things:
```
error[E0428]: the name `U1024` is defined multiple times
```
This comes from the typenum library. The issue was fixed in 14a3322d10, so all it takes is an upgrade of the crate.
Differential Revision: https://phabricator.services.mozilla.com/D74005
This commit adds syncing support to the `StorageSyncArea` class, via
the Golden Gate library.
It also changes the `BridgedEngine` trait: `initialize` and `finalize`
haven't been useful in practice, since that's managed by the storage
service, and the `LazyStore` takes care of setting up the storage
connection on first use. But, what we do need is a way to signal a
sync is starting, so that the engine can set up temp tables. That's
handled by the new `sync_started`.
Finally, this commit changes `BridgedEngine::set_uploaded` to take a
`sync15_traits::Guid` instead of a `String`.
Differential Revision: https://phabricator.services.mozilla.com/D73415
This commit splits `CryptoWrapper` into a base `RawCryptoWrapper`
class, which only handles encryption and decryption without
parsing the cleartext's contents, and the existing `CryptoWrapper`
class, which works like before.
Our bridged engine subclasses `RawCryptoWrapper`, and
implements some methods to convert records to and from envelopes.
Envelopes are a concept we introduced in `sync15_traits` to pass
along metadata from the BSO wrapper (like the modified time from the
server, and ID, to ensure they match) in addition to the cleartext.
This lets us reuse `sync15_traits::Payload` to parse record payloads
in Rust, and avoids parsing the cleartext in JS, only to stringify it
again when we pass it to the bridged Rust engine.
Differential Revision: https://phabricator.services.mozilla.com/D73581
This commit adds a `mozIInterruptible` implementation to
`StorageSyncArea`, and changes `LazyStore` to get an a-s interrupt
handle and interrupt pending operations.
Differential Revision: https://phabricator.services.mozilla.com/D73414
This commit removes the `nsICancelable` return values from all
`mozIBridgedSyncEngine` methods, and replaces them with a
`mozIInterruptible` interface that can be implemented by store
classes that support interrupting.
The `nsICancelable` pattern was intended to make each operation
interruptible, without affecting the others. But we can't guarantee
that with SQLite, because it only has a way to interrupt all
running statements on a connection, not specific ones. Further,
this pattern doesn't match what we currently do in a-s, where we
create an internal "interrupt scope" for each operation, and hand
out an "interrupt handle" for interrupting all in-progress
operations.
Storage classes like `StorageSyncArea` can opt in to interruption
by implementing `mozIInterruptible`. It's a separate interface to
protect against accidental misuse: because it interrupts all
statements on the connection, it might lose writes if the current
operation is a `set`, for example. But it's useful for testing and
debugging, so we still expose it.
This commit also changes Golden Gate ferries to hold weak references to
the `BridgedEngine`, so that they don't block teardown.
Differential Revision: https://phabricator.services.mozilla.com/D73413
the drop order of adapter fields made it so the handle to DX12 DLL was dropped before
the last resources are destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D73456
This commit wires up `StorageSyncArea::teardown()` to call the new
`webext_storage::Store::close()` method.
It also changes `teardown` to drop the `LazyStore`, and thus close its
database connection, on the main thread if dispatching to the task
queue fails. Dispatch should only fail at shutdown, and putting the
owned reference back only adds indirection, since the `StorageSyncArea`
will still drop its `LazyStore` later in shutdown.
Finally, it includes an xpcshell test fix for
https://github.com/mozilla/application-services/pull/3050.
Differential Revision: https://phabricator.services.mozilla.com/D72992
Now that `BridgedEngine` has been moved to `sync15_traits`, we can
remove `golden_gate_traits` from the tree, and change Golden Gate to
depend on `sync15_traits` directly.
This commit also adds a Cargo feature, `services_sync`, which reflects
the `MOZ_SERVICES_SYNC` config option. In the future, we'll use this
feature to gate implementations of `mozIBridgedSyncEngine`.
Differential Revision: https://phabricator.services.mozilla.com/D72784
The `webext_storage_bridge` crate introduced in this commit bridges the
`mozIExtensionStorageArea` XPCOM interface to the `webext_storage` Rust
component from Application Services.
This commit factors out the following parts from bug 1623245, so that
we can land them piecemeal:
* The `mozIExtensionStorageArea` interfaces, which implement all the
methods needed to support the `storage.sync` API.
* A Rust implementation of the above, in `StorageSyncArea`.
* A `StorageTask` type, for dispatching storage operations to a
background task queue.
* A `LazyStore`, which wraps the Rust component's `Store` and lazily
initializes it on the background queue the first time it's used.
* A `StorageSyncService`, which is our singleton. It holds on to a
configured `StorageSyncArea`, and hands out references to it via
`getInterface`. Eventually, we'll extend this to support syncing,
too.
Differential Revision: https://phabricator.services.mozilla.com/D71897
Hooray, our first Application Services Rust component! This is a
mechanical run of `mach vendor rust`, split out into its own commit
to make reviewing the Firefox bindings easier.
Differential Revision: https://phabricator.services.mozilla.com/D71895
The `webext_storage_bridge` crate introduced in this commit bridges the
`mozIExtensionStorageArea` XPCOM interface to the `webext_storage` Rust
component from Application Services.
This commit factors out the following parts from bug 1623245, so that
we can land them piecemeal:
* The `mozIExtensionStorageArea` interfaces, which implement all the
methods needed to support the `storage.sync` API.
* A Rust implementation of the above, in `StorageSyncArea`.
* A `StorageTask` type, for dispatching storage operations to a
background task queue.
* A `LazyStore`, which wraps the Rust component's `Store` and lazily
initializes it on the background queue the first time it's used.
* A `StorageSyncService`, which is our singleton. It holds on to a
configured `StorageSyncArea`, and hands out references to it via
`getInterface`. Eventually, we'll extend this to support syncing,
too.
Differential Revision: https://phabricator.services.mozilla.com/D71897
Hooray, our first Application Services Rust component! This is a
mechanical run of `mach vendor rust`, split out into its own commit
to make reviewing the Firefox bindings easier.
Differential Revision: https://phabricator.services.mozilla.com/D71895