- Updated `Cargo.toml` to point to the app-services commit with the fix
- Reverted my default rust to `1.86.0`
- Ran `./mach configure` and `./mach vendor rust`
Differential Revision: https://phabricator.services.mozilla.com/D266197
Bug 1959801 removed the `remove_dir_all` crate. However, there was a regression we didn't discover until Firefox 140 reached stable: third-party DLL injection on Windows caused problems for the call sites that had had usages of `remove_dir_all::remove_dir_all` replaced with `std::fs::remove_dir_all`!
DLL injection by third parties were causing these crashes because they incorrectly detour calls to `NtOpenFile`, crashing with Rust's current usage of it in `std::fs::remove_dir_all`. The issue has been reported upstream as [rust#143078], and a mitigation is in place in Rust's Nightly release channel. At time of writing this patch message, the fix is projected to become available in a stable Rust toolchain with version 1.90—roughly 11 weeks away.
[rust#143078]: https://github.com/rust-lang/rust/issues/143078#issue-3181510282
After considering multiple mitigation options, this patch represents the decision of some stakeholders (@gstoll, @dmeehan, @yjuglaret, @gsvelto, @leggert, @ErichDonGubler) to mitigate the issue by directly backing out the patch for bug 1959801. The current plan is to eventually remove `remove_dir_all` again, once Rust 1.90 becomes the minimum supported version for `mozilla-central` (see bugs linked against bug 1973947 for more details), thus guaranteeing that our usage of `std::fs::remove_dir_all` is robust against this issue.
We may or may not engage with third parties to fix DLL injection; it has
not been decided at this time.
Original Revision: https://phabricator.services.mozilla.com/D256027
Differential Revision: https://phabricator.services.mozilla.com/D256040
This vendors this revision:
8986582d37
It also makes some desktop fixes due to some breaking changes in Suggest, which
@daisuke previously reviewed. It's a large vendor due to vendoring some new
crates plus some app-services revisions that made changes to logging and error
reporting and touched lots of files.
Differential Revision: https://phabricator.services.mozilla.com/D250877
As far as I can tell, this code does not rely on the slight differences provided by the `remove_dir_all` crate that make it different than `std::fs::remove_dir_all`, but #gfx-reviewers should please confirm that.
Differential Revision: https://phabricator.services.mozilla.com/D245133
The eventual goal is to enable using the new IR pipeline code, but this
commit simply switches over to the new version. The main change is that
UniFFI is back to using askama as the template engine, since rinja
project has been merged back in.
Differential Revision: https://phabricator.services.mozilla.com/D247843
This incorporates (and obsoletes) @bdk's vendor in D246633 and content relevancy
fixes in D246326, and @daisuke's Yelp fixes in D243740, plus another small Yelp
fix.
Differential Revision: https://phabricator.services.mozilla.com/D246794
Split out, because the upgrades are split into multiple commits, but we
require a single vendoring to avoid duplicated packages.
Differential Revision: https://phabricator.services.mozilla.com/D241959
Notable WebGPU CTS changes:
- Demotions from tier 2 to tier 3:
- `webgpu:shader,execution,expression,unary,{i32,u32}_conversion:f32:*` started regressing on Windows.
- Promotions to tier 2 from tier 3:
- Across all platforms:
- `webgpu:shader,execution,expression,call,builtin,cross:f32:*`
- `webgpu:shader,execution,expression,unary,i32_conversion:abstract_float:*`
- `webgpu:shader,execution,expression,unary,u32_conversion:abstract_float:*`
- `webgpu:shader,execution,limits:nesting_depth_braces:*`
- `webgpu:shader,validation,expression,call,builtin,value_constructor:vector_copy:*`
- `webgpu:shader,validation,expression,call,builtin,value_constructor:vector_elementwise:*`
- `webgpu:shader,validation,expression,call,builtin,value_constructor:vector_mixed:*`
- `webgpu:shader,validation,expression,call,builtin,value_constructor:scalar_zero_value:*` was promoted on Linux and Windows, but stays in macOS on account of failing `f16` functionality. My guess is that these failures are also present on the other platforms, but we don't see the because `shader-f16` is not aviailable on our other CI platforms yet.
- From macOS, completing the set of all platforms passing:
- `f16` functionality, which, again, was likely not visible on our other CI platforms before:
- `webgpu:shader,execution,expression,call,builtin,cross:f16:*`
- `webgpu:shader,validation,decl,override:type:*`
- `webgpu:api,validation,capability_checks,limits,maxUniformBufferBindingSize:createBindGroup,at_over:*`
was promoted on Windows.
Differential Revision: https://phabricator.services.mozilla.com/D243593
