Taiki Endo

cdylib itself should be supported since cargo-llvm-cov works with PyO3 and proc macros (https://github.com/taiki-e/cargo-llvm-cov/issues/304 https://github.com/taiki-e/cargo-llvm-cov/pull/307) If it does not work, it is generally the case that the required environment variables...

Thanks for the repro. > 4\. `cargo b`; The first problems is that the `libfoo.so` built in this step is not instrumented. (In other words, the environment variables necessary to...

Binaries are supported, but coverage is not collected if the process is killed without completing (https://github.com/taiki-e/cargo-llvm-cov/issues/235, limitation of LLVM/rustc.) If it does not work, please provide a reproduction of the...

> Before opening this issue ticket, I have tested it by inspecting `std::env::var("RUSTFLAGS")` in `build.rs` but an `Err` was returned. Since Rust 1.55, Cargo does not pass the RUSTFLAGS environment...

Thanks for the PR! - CI failure has been fixed in #111. - Could you add regression tests for these unsoundness? (e.g., ui test to make sure that problematic cases...

It seems that the MSRV bump triggered a new clippy warning. Could you address that as well? ``` error: initializer for `thread_local` value can be made `const` --> async-stream/src/yielder.rs:37:45 |...

inline const in thread_local is special and is available since Rust 1.59: https://github.com/rust-lang/rust/pull/91355

Published in 0.3.6.

I don't remember exactly what happened, but I suspect I could not publish without removing it due to circular dependencies. https://github.com/tokio-rs/tokio/blob/b32826bc937a34e4d871c89bb2c3711ed3e20cdc/tokio-test/Cargo.toml#L22

This is for workaround a Cargo bug and is not a problem that can be addressed on our end at this time. See the linked issues.