Taiki Endo
Taiki Endo
> * Do you have something in mind for the impl, or would you like us to have a go and PR to portable-atomic? > * What do you think...
> It sounds like using the `critical-section` impl would be more straight forward I think, but if you have some of the scaffolding ready for the global sharded lock, then...
Cargo itself can be free to modify the lockfiles as long as no `--locked` or similar is passed, right? If so, I think we could just skip the use of...
I think what I mentioned at the end of https://github.com/rust-lang/cargo/pull/13523#issuecomment-1975027985 is the only way we can do well here without additional flags or breaking changes.
Considering cargo's behavior around weak dependencies and namespace features (https://github.com/eupn/macrotest/pull/108#issuecomment-2028018098), I feel it would work well to call generate-lockfile only if the MSRV is pre-1.60. I think it was around...
wasm-pack has an issue with Rust 1.82 (https://github.com/webpack/webpack/issues/15566), so pinning rust toolchain to 1.81 may fix the problem.
Fixed in the recent wasm-pack
This appears to be a duplicate of https://github.com/rust-lang/futures-rs/pull/2763?
I guess this is a cargo-expand or rustc issue since the macrotest fails if the cargo-expand exits with a non-zero code.
Thanks for starting this! > And the first input would be `error: doctest is not supported for nextest` while running `cargo llvm-cov nextest ... --doctests`. > Cc #2 Lack of...