Taiki Endo

I think this is a great idea. I would accept a PR to implement this.

I would accept a PR to re-use 1.x.y toolchain as 1.x toolchain when it is the latest point release.

I don't think there is currently a way to do this with a single command. (`--group-features` treats the specified features as if it were a single feature.) If you are...

I'm okay with adding a flag for such use-case, but given that cargo itself does not recommend the use of mutually exclusive features, we will probably need documentation to warn...

https://github.com/taiki-e/cargo-hack/issues/132#issuecomment-947800980 >> If it is not possible, consider adding a compile error to detect this scenario. Btw, #115 is a feature request to check that a proper compilation error occurs...

We can avoid a breaking change by adding this as a reexport of `pin_mut!`. Then, remove `pin_mut!` in the next major version. (Actually, I would like to deprecate pin_mut in...

Hmm, I don't have the publish permission of `pin-utils`. @MajorBreakfast @cramertj Would you give me the publish permission of [`pin-utils`](https://crates.io/crates/pin-utils)?

> He used the `join!` macro to poll them in parallel, but was disappointed to see that the tooling he was accustomed to, such as rustfmt or rust-analyzer didn't work...

The compatibility issue with rust-analyzer has been fixed in futures [0.3.15](https://github.com/rust-lang/futures-rs/releases/tag/0.3.15). > - Use `#[proc_macro]` at Rust 1.45+ to fix an issue where proc macros don't work with rust-analyzer (rust-lang/futures-rs#2407)

it shouldn't probably be difficult to integrate both io traits once https://github.com/rust-lang/rust/issues/69941 and https://github.com/rust-lang/rust/issues/78485 are stable. AFAIK, they should be sufficient to meet the requirements that tokio requires for async...