ridwanabdillahi

> You can actually specify which crates to test when giving the `cargo test` command in a workspace. I think this RFC should talk about this scenario right now instead...

> Good update. But I still see some references to "top-level crate" which is a bit confusing with the new changes. I've removed the references to `top-level crate`. Thanks for...

@epage thank you for taking the time to review this PR, it is greatly appreciated. I've made the updates you requested and added doctests to the initial iteration of this...

Thank you for your response @nrc > It should be a platform for supporting all things, but only include default support for core functionality. I don't think code coverage makes...

> If I'm understanding plugins correctly then Tarpaulin is already a coverage plugin for cargo (among others) https://lib.rs/crates/cargo-tarpaulin Yes, Tarpaulin is a plugin along with llvm-cov. > The only concern...

@nrc As per our discussion, I pushed out a separate RFC to support a generic mechanism for setting rustc flags via Cargo. This allows setting any Rust compiler flag, not...

@ssokolow I agree with this sentiment, thus the reason for opening this RFC. In my opinion having support for code coverage integrated directly into Cargo would be extremely helpful for...

> One quick note — I would want to make sure this knows to not clobber between coverage and non-coverage artifacts so that the last two calls in this sequence...

Ahh I understand your comment now. That is very interesting, my only worry about this adding additional artifacts for each crate that is being instrumented and potentially having 'coverage artifacts'...

@ehuss Thanks for the detailed response! Yes, that hack should be sufficient enough to use as a workaround for the main issue of using third-party commands to handle collecting code...