- 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
This reverts commit d810bb578e.
Revert "Bug 1955298 - uniffi-bindgen-gecko-js: start using the IR pipeline, r=markh,frontend-codestyle-reviewers"
This reverts commit fe3e643fee.
Updated the uniffi-bindgen-gecko-js code to use two things I've been
experimenting with:
* Use the IR pipeline code to generate the structs used to render the
templates.
* A new test fixture for bindings generators. This one targets bindings
generators specifically, it doesn't try test the scaffolding code and
it's not based on real-world example code. I originally thought it
would be a single crate, but I ended up needed 2 in order to test
external types. (https://bugzilla.mozilla.org/show_bug.cgi?id=1948961)
Differential Revision: https://phabricator.services.mozilla.com/D242385
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
This reverts commit bcf4989b84.
Revert "Bug 1955298 - uniffi-bindgen-gecko-js: start using the IR pipeline, r=markh,frontend-codestyle-reviewers"
This reverts commit 6e1a647b81.
Updated the uniffi-bindgen-gecko-js code to use two things I've been
experimenting with:
* Use the IR pipeline code to generate the structs used to render the
templates.
* A new test fixture for bindings generators. This one targets bindings
generators specifically, it doesn't try test the scaffolding code and
it's not based on real-world example code. I originally thought it
would be a single crate, but I ended up needed 2 in order to test
external types. (https://bugzilla.mozilla.org/show_bug.cgi?id=1948961)
Differential Revision: https://phabricator.services.mozilla.com/D242385
This reverts commit 02d50105b9.
Revert "Bug 1955298 - uniffi-bindgen-gecko-js: start using the IR pipeline, r=markh,frontend-codestyle-reviewers"
This reverts commit 90368cc237.
Updated the uniffi-bindgen-gecko-js code to use two things I've been
experimenting with:
* Use the IR pipeline code to generate the structs used to render the
templates.
* A new test fixture for bindings generators. This one targets bindings
generators specifically, it doesn't try test the scaffolding code and
it's not based on real-world example code. I originally thought it
would be a single crate, but I ended up needed 2 in order to test
external types. (https://bugzilla.mozilla.org/show_bug.cgi?id=1948961)
Differential Revision: https://phabricator.services.mozilla.com/D242385
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 sets up the scaffolding on the Rust side and calls that from the
C++ side.
To start it only measures the size of pings.
This requires a Glean update that implements all that malloc_size_of.
Differential Revision: https://phabricator.services.mozilla.com/D210288
On macOS and Windows, the underlying implementations of the OS APIs that
provide access to keys and certificates are not necessarily thread-safe. Before
this patch, essentially all calls into osclientcerts would be synchronously
forwarded to a single background thread. Unfortunately, the cost of dispatching
and waiting for all of these events was non-trivial, particularly when the vast
majority of them should essentially be no-ops (e.g. when NSS is looking for CA
certificates or trust information, etc.). This patch reworks the implementation
to only dispatch operations involving OS APIs to the background thread.
Differential Revision: https://phabricator.services.mozilla.com/D246520
On macOS and Windows, the underlying implementations of the OS APIs that
provide access to keys and certificates are not necessarily thread-safe. Before
this patch, essentially all calls into osclientcerts would be synchronously
forwarded to a single background thread. Unfortunately, the cost of dispatching
and waiting for all of these events was non-trivial, particularly when the vast
majority of them should essentially be no-ops (e.g. when NSS is looking for CA
certificates or trust information, etc.). This patch reworks the implementation
to only dispatch operations involving OS APIs to the background thread.
Differential Revision: https://phabricator.services.mozilla.com/D246520
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
