cargo test gives up compiling after one error

[lopopolo]

I'm making a big refactor. When attempting to clean up my tests, cargo test appears to go file by file, alphabetically when compiling the tests. As soon as one #[test] has a compile error, the build is aborted.

• #[test]s following the failure do not get compiled.
• Subsequent compile errors in the #[test] that fails to build are not reported.

This makes finding errors very tedious.

---

Editing to provide concrete case:

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=c040edc58966f3fcc662002e84ec57aa gives up after the first test but should continue to report errors

[Mark-Simulacrum]

What error specifically? Can you post a build log and a link to a repo (or, ideally, playground) that reproduces this behavior?

[lopopolo]

I know there are errors in the build. The problem is that cargo test stops compiling all of the tests once it encounters a single error.

[lopopolo]

@Mark-Simulacrum This playground gives up after compiling foo test:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=c040edc58966f3fcc662002e84ec57aa

[Mark-Simulacrum]

This has nothing to do with tests and is just a consequence of how type inference errors are currently fatal in this case. Removing the #[test] annotations leads to the exact same error.

I'm going to close this issue as it's not really something that's fixable (well, it is, but not a targeted fix, and there's no real need to track this case separately). Thanks for the bug report, though!

[lopopolo]

Is there a bug for the broader issue that I can watch?

[Mark-Simulacrum]

Not really in the sense that it's not a bug just a consequence of the current implementation.

[estebank]

I believe this is a valid bug report. A cursory look at the code tells me that we are being overeager in how much we silence here. At least, we should only silence inside of a given body instead of globally like we do now.

CC #21974