Constant evaluation cannot have code coverage instrumentation about rust HOT 9 OPEN

Yes it will, but the approach of "just" having your test call the const fn at runtime will still work. So it seems to me like if coverage matters, you can keep obtaining coverage that way.

from rust.

@rustbot label +A-code-coverage

from rust.

Could you update the issue description to start by explaining the problem -- in the usual way, "here's my code, here's what I did, here's what happened, here's what should have happened"? Currently it starts by saying "the problem is hard" without saying what the problem is. I was confused for a while here. Of course there's no coverage instrumentation, it's compile-time code after all...

from rust.

Right, I was avoiding providing explicit code examples because I felt that it might get a bit too in the weeds, but I'll try and add one to make it a bit easier to understand.

from rust.

Updated the description with hopefully a better example. Keep in mind that as I said, I don't think that this feature is worth having now given my current example, but as more stuff gets stabilised for const evaluation, it feels like this would be more and more desired.

from rust.

const fn can be called at compiletime and runtime, so I am not entirely sure why there would be code duplication.

To test the normalization code, I decided to create a bunch of sample spring states and compared their values in the test, but because I wanted to share them across tests, I constructed them in constants. This caused the normalization code to be entirely absent from code coverage, since it happened at compile time. Since the normalization after various operations isn't the same as the normalization in the constructor, the tests for those also didn't affect the constructor's code coverage.

There is another way to share them: write functions of type const fn f() -> T. Then you can call these functions at runtime and will get coverage information.

Arguably that's still a work-around, but the overhead compared to using consts in your tests seems rather small.

from rust.

const fn can be called at compiletime and runtime, so I am not entirely sure why there would be code duplication.

There is another way to share them: write functions of type const fn f() -> T. Then you can call these functions at runtime and will get coverage information.

Arguably that's still a work-around, but the overhead compared to using consts in your tests seems rather small.

Oh, like I said, I completely agree that this would mostly be overkill with the current state of const evaluation. It mostly just prompted the idea for me since I know that const eval will become substantially more advanced in the future.

from rust.

if it's not too much complexity in the mir interpreter, could the interpreter collect the coverage data during evaluation and then have it exposed at the use runtime sites of the constant? As long as most of the complexity is in the coverage logic and not the interpreter, that seems maintainable to me.

from rust.

Coverage instrumentation in miri in general feels like something that would be useful to have, although I'm not sure if that's already possible or not. Since the compiled code already links back to the original source, I would assume that the MIR also has access to the original source as well for storing that info.

from rust.