Open
Description
Similarly to what is being done in LLVM and Clang: https://reviews.llvm.org/D84467.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Similarly to what is being done in LLVM and Clang: https://reviews.llvm.org/D84467.
Activity
mati865 commentedon Jan 8, 2021
cc @richkadel you might want to include it in #79121
richkadel commentedon Jan 8, 2021
Actually, at last I checked, this is not in any stable version of LLVM yet. I think it's feasible to stabilize Rust coverage in rustc, based on the current feature of LLVM InstrProf, without depending on proposed future LLVM features. So, IMO, I don't think we should add this to the tracking issue, as a dependency. In fact, until this capability is stabilized in LLVM, and available in a version of LLVM that's supported by rustc, I think it makes sense to keep this as a stand-alone feature request / enhancement.
Let me know if any of my assumptions are incorrect.
richkadel commentedon Jan 8, 2021
Cc @tmandry
mati865 commentedon Jan 8, 2021
I have no idea how adding features like that works, I thought it will be available right away in LLVM 12 around March.
tmandry commentedon Jan 9, 2021
Neat. This would certainly improve the way we present coverage for these things, and might make it possible to be more intuitive about how we handle closing braces.
Just to throw it out there, since I'm thinking about async/await right now: This does offer an intriguing possibility of measuring drops at await points. It's possible for buggy code to assume it will never get canceled at an await point, when in fact that's part of the contract. It would be nice if we could highlight this in coverage results. Though explicitly testing cancelation at every await point sounds daunting...
It should be there in the next major version of LLVM, whenever that is.
matthargett commentedon May 6, 2022
Looks like this feature was released in LLVM 12.0.0:
https://releases.llvm.org/12.0.0/docs/CoverageMappingFormat.html
14.0.0 was released 2022 March. Similar to the approved suggestion in other issues, where it was decided that an LLVM 11 feature could be used once LLVM 13 was released, could the requirement for code coverage working now be LLVM 12?
I see the original umbrella tracking issue for standardized Rust coverage options still has a few issues open, but it otherwise looks stable and settled.
47 remaining items