Taiki Endo

Results 938 comments of Taiki Endo

AFAIK, the situation on this platform is similar to x86_64-pc-windows-gnu (this is an upstream bug and the use of LLD as a liker or *-pc-windows-gnullvm target may work): https://github.com/taiki-e/cargo-llvm-cov/issues/254

I think this will be supported in https://github.com/rust-lang/rust/pull/124154 or https://github.com/rust-lang/rust/pull/130744.

``` error: the `cargo::` syntax for build script output instructions was added in Rust 1.77.0, but the minimum supported Rust version of `generator v0.8.3` is 1.77. See https://doc.rust-lang.org/cargo/reference/build-scripts.html#outputs-of-the-build-script for more...

This means that some of the code generated by the assert_eq macro is not covered, but I believe this is an upstream bug anyway. (It is somewhat similar to https://github.com/rust-lang/rust/issues/98712.)...

Closing in favor of upstream bug report (https://github.com/rust-lang/rust/issues/84892).

I think you can use [LLVM_COV_FLAGS environment-variable](https://github.com/taiki-e/cargo-llvm-cov?tab=readme-ov-file#environment-variables), but I'm okay with adding a specific option for out-of-target-dir object files.

> ``` > # This seems to expect profraws in `target/debug`, and hence finds nothing and errors. > ``` It expects both [profraws](https://github.com/taiki-e/cargo-llvm-cov/blob/bab773225daf2763eeeed6399f87a651a65f825d/src/main.rs#L621) and [objects (binaries)](https://github.com/taiki-e/cargo-llvm-cov/blob/bab773225daf2763eeeed6399f87a651a65f825d/src/main.rs#L665) to be in the...

As for the issue about `cargo llvm-cov report`, I think the option added in https://github.com/taiki-e/cargo-llvm-cov/pull/355 is needed. The other may have been solved in https://github.com/taiki-e/cargo-llvm-cov/pull/349.

> It's quite popular I would say: https://github.com/search?q=BoxTryFuture&type=code Only 4 seem to be unique (tide, tinychain, txn_lock, tokio-tide, and tokio-tide's code is in comment). All the others seem to be...

Thanks for the PR. I would prefer not to use spinlock by default around operations that would involve allocations even if it is no_std-only. That said, it might be fine...