Hi!
I got unexpected dead code warnings when executing cargo test with multiple test files. I use a very simple example below that reproduces the issue.
I have two files that contains tests, tests/test_one.rs and tests/test_two.rs. Both contains exactly the same content (except for the unique test function name they contain):
mod routines;
#[test]
fn test_one() {
routines::my_routine();
}
And another file called tests/routines.rs that simply contains:
pub fn my_routine() {
}
When I execute cargo test, the two tests are executed successfully and there is no raised warning. But if I remove the my_routine() call from one of the two tests, cargo test stills end up successfully but raises a warning on pub fn routine() saying function is never used. However, one test still calls the function, so there is no dead code as stated.
I got the same issue with both rust stable (1.22.1) and rust nightly (1.24.0).
Thanks.
This is not actually a bug, as far as I know!
And another file called tests/routines.rs that simply contains:
Cargo is also attempting to compile this file as its own test. See the explanation here: https://doc.rust-lang.org/book/second-edition/ch11-03-test-organization.html#submodules-in-integration-tests
I believe if you move this file to tests/routines/mod.rs, this will work without warning.
Yes, when replacing tests/routines.rs by tests/routines/mod.rs, Cargo does not attempt to compile routines.rs as a test.
But, the warning is still raised at the first execution of cargo test (and only at the first execution).
Here the details of what I do after changing tests/routines.rs to tests/routines/mod.rs:
cargo test multiple times with two calls to my_routine() (one in each test) -> no warningmy_routine() from one of the two testscargo test -> one warning function is never used is raised for my_routine()cargo test again (without code modification) -> no warning anymoreFor exactly the same code, cargo test outputs a warning only during the first execution. Furthermore, for each execution, the two tests are run so my_routine() is called. Maybe I just miss something, but this is kind of weird, isn't it ?
I believe cargo compiles each "integration test" (i.e. file in tests/*.rs) independently. So if the helper in a common module tests/routines/mod.rs is used in tests/test_one.rs, but not in tests/test_two.rs, there will be a warning when compiling test_two.rs.
(cargo test re-builds only what needs to be rebuilt, that's why it only warns on the first execution.)
I've worked around this by using mod routines; pub use routines::*; in tests/*.rs.
So we're running into the same issue and I think the workaround mod routines; pub use routines::*; is not optimal as that does hide truly dead code. I think this is a legitimate cargo bug.
This is either a bug or a design flaw.
In TypeScript, an exported item (even if it is never used) is never considered dead code. I don't why it is in Rust.
@KSXGitHub well, if you export the items from the crate with mod routines; pub use routines::*; it's not considered dead code.
What @svenstaro is asking for would require considering all targets/configurations before determining if an item is dead code instead of letting the rust compiler report them when compiling an individual crate...
I am noticing this issue,
when will the PR above be released in rust ? ^
We are encountering the same issue. I am not sure I am comfortable with no dead code warnings. Perhaps an alternative approach to organizing code people would suggest if there is no re-design any time soon?
If the module is implemented in tests/routines/mod.rs, just using pub mod routines;, in every test file that I wish to use routines module, solved the problem for me. This works as expected, imo, because:
routines at all.So, it looks to me that exported stuff is also not considered a dead code in rust, but it needs to be declared/imported with pub.
There is a nice example of the similar use-case in the rust book: https://doc.rust-lang.org/1.29.2/book/2018-edition/ch07-02-controlling-visibility-with-pub.html.
We are still encountering this issue with the last version of Rust (1.45.0 nightly)
Most helpful comment
We are still encountering this issue with the last version of Rust (1.45.0 nightly)