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
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
