The test infrastructure in Rust currently distinguishes between unit tests, i.e., those in the same file as the tested function and integration tests, i.e., those within the tests/ directory. The integration tests are handled differently to the unit test as they are treated like an external crate which uses the developed library. Further each integration test file is treated as its own compilation unit.
Currently when invoking cargo test encounters a compile error within an integration test, the test compilation is aborted an no tests are executed—neither unit tests nor other integrations tests.
Stopping test execution if a compile error is encountered within a unit test is fine in my opinion as this indicates an error in the library itself. However for integration tests I think it would be reasonable to stop only the failing compilation unit.
Especially when developing proc_macros testing the correctness of the generated code relies on integration tests. Though before being able to test the semantics of a single integration test, the code generation must be syntactically correct for all integration tests. If you write the test before the implementing the code, e.g., to get a feel for the macro usage this is cumbersome as you have to disable tests manually before testing already implemented parts. Also forgetting to reenable an integration test would be serious problem.
I would propose to mark integration tests whose compilation fails with compilation failed to indicate syntactic error—similar to failed which is used for semantic errors—and proceed with the remaining integration tests. Would you consider this to be useful/reasonable behaviour for cargo test?