Brian Smith

My current perspective is that it is annoying to others to be depending on getrandom 0.2 when getrandom 0.3 is available, so it is worth somebody trying to resolve things....

I haven't completed the review of getrandom 0.3 yet. Currently we can't use getrandom 0.3 for wasm32-unknown-unknown because getrandom 0.3 doesn't provide a way for our `wasm32_unknown_unknown_js` feature to work....

One solution would be to vendor the getrandom 0.3 wasm_js.rs backend code, and use the vendored code if and only if `wasm32_unknown_unknown_js` feature is enabled and the `getrandom_backend` cfg directive...

I don't intend to work on this myself but I would accept a PR that implements "First PR" above.

The workaround above is basically what the `uuid` crate did: https://github.com/uuid-rs/uuid/pull/793, https://github.com/uuid-rs/uuid/pull/794, https://github.com/uuid-rs/uuid/pull/804, though I think looking at `cfg(getrandom_backend)` would have been a better choice for them.

Why not use `Add-PartitionAccessPath -DiskNumber -PartitionNumber -AccessPath $mount_path` to mount some folder on `C:\` as `D:\` to maintain backward compatibility?

See PR #875 and PR #876, which suggest the dependency could just be eliminated completely.

The tests added in PR #1384 are important for preventing regressions and more tests along those lines are needed. In the last year or so there have been lots of...

This is blocked on me doing the pre-release testing. Unfortunately, some of the infrastructure I have for this, especially aarch64-windows-msvc machines, are not available to me currently. I filed #2526...

I started the work for aarch64-pc-windows-msvc in https://github.com/briansmith/ring/pull/2529. Unfortunately, it seems there are multiple compatibility-breaking changes in Rust 1.87 and Rust Nightly that are blocking this. I addressed one of...