Build subcommand or option that builds all targets (including tests)

[bruno-medeiros]

Currently cargo build will build the lib target and the bin targets, but none of the test targets.
cargo test --no-run will build the tests targets (and the lib target), but not the bin targets.

Ideally, there should be a cargo build command or option that would build all the crate's targets. Not just for convenience and (possibly) better performance, but also to be be able to integrate future cargo build options and have them apply to the test targets builds too. For example, using "cargo check" or something similar. (#1313)

[alexcrichton]

Could you expand on the motivation for this? I can't really think of a use case for "build everything" unless you want to actually use everything right afterwards...

[bruno-medeiros]

Well:

• You know your change might break the execution of your tests, but you don't want to run them straight away - because generally speaking, they take a long time to run. So mentally you accept your change might break the tests execution (and that's a problem for later), but you still want to verify now that the tests compile, at the very least.
• You do a change you expect will not break the tests at all (for example, renaming some element). But you do a mistake (perhaps you forgot to rename some reference in the tests) and that change does break the tests compilation. You'd want to be able to check that by just building the whole crate.

These scenarios happen to me very often in Java projects I work with. And with Rust I'm also now using cargo test --no-run as my default crate build method. (Since tests are a lot more code, and they change much more frequently, than bin targets, so I'd rather forsake the bin targets first)

[alexcrichton]

Hm it sounds like cargo test --no-run solves both these cases? Are there parts that command doesn't compile?

[bruno-medeiros]

Hm it sounds like cargo test --no-run solves both these cases? Are there parts that command doesn't compile?

I mentioned above that it doesn't build the bin targets, but upon trying it again, it seems it does, so I guess I was wrong in my understanding. So yeah, it seems like cargo test --no-run builds all tests, that's good.

I'm happy with this, as long as gong forward cargo test --no-run gets the same sub-options that get added to cargo build, for example the ability to output JSON (#1403), or something like cargo check (#1313).

[bruno-medeiros]

After some user reports of cargo test --no-run not working as expected under IDE usage, I've found out what the problem was: it only generates the bin targets if there is a test target (either explicit [[test]] in Cargo.toml or just a tests/blah.rs file) in the crate. Reopening.
(This explains my original misunderstanding of whether cargo test --no-run was building bin targets or not)

[alexcrichton]

Oh interesting! I thought binaries were at least compiled with --test, but are they marked with test = false?

[bruno-medeiros]

They are not marked with test=false, but even if they are, it makes no difference for the problem mentioned above. With test=false, the executable for the implicit test target of the bin target (I don't know a better term) is not generated.
But the executable I complain about not being generated is the executable for the bin targets themselves, the ones running fn main(), not a tests executable.

[bruno-medeiros]

I just realized (in case it wasn't clear), it's not just that the target/*.exe executables are not generated for the bin targets, but none of the compilation and error checking is done. So if there are error in main.rs or so, they are not checked. (again, except it there are tests targets defined...)

[alexcrichton]

Hm so to confirm, the only situation I believe where executables are not compiled are when integration (tests/* or [[test]]) tests are missing. If those exist then the executables should always be compiled.

This choice was done because if integration tests are missing the executables are still compiled with --test by default, meaning they get a chance at all the same normal checks. Additionally it means incremental changes to executables don't need to compile two things on a cargo test.

Does that make sense? Can you confirm that the bad behavior you're seeing only happens in projects with no integration tests?

[bruno-medeiros]

Does that make sense? Can you confirm that the bad behavior you're seeing only happens in projects with no integration tests?

Yes, that's correct. Apparently even a blank .rs file in tests/ works as a workaround, I've been using that in my projects: https://github.com/RustDT/RustLSP/blob/master/tests/dummy.rs