Comments (9)
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.
Related Issues (20)
- `tests/run-make/print-target-list` fails for csky-unknown-linux-gnuabiv2 HOT 3
- Missing implied bound raises misleading error message HOT 3
- Tracking issue for pub_use_of_private_extern_crate future-compatibility lint
- Degradation from rustc 1.71.0 -> 1.79.0 ("infinite space" compile error not recognized anymore) HOT 6
- type alias `Plus2` is never used HOT 10
- The Android CI prints unrelated things to stdout, ruining check-run-results tests. HOT 2
- conflicting errors: `index out of bounds` HOT 2
- ICE: delegation: `unexpected parent of trait or impl item or item not found` HOT 1
- run-make: revise rmake.rs setup in compiletest
- Unconstrained lifetimes in impl headers are usable in assoc consts
- don't suggest turning crate-level attributes into outer style HOT 1
- Remove `binary_asm_labels` once the LLVM issue is fixed
- `asm!` lints based on `cfg` rather than target HOT 3
- `std::ptr::drop_in_place` docs suggest overwriting value with `write`, which can lead to unsoundness in common cases HOT 6
- assertion left==right failed in rustc_query_system/src/dep_graph/serialized.rs HOT 2
- Tracking Issue for `debug_more_non_exhaustive`
- rustdoc leaks private types in Implementations on Foreign Types HOT 1
- bootstrap: `profile = "tools"` contains incompatible options. HOT 2
- ICE "Failed to extract DefId" HOT 1
- Request for `tune-cpu` code generation option to be promoted to stable HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rust.