Cargo doesn't always produce diagnostics

[mooman219]

Running cargo check will produce no output until a file is modified. The GIF shows this happening in the integrated terminal, but this also happens when running in a stand-alone terminal. Cargo will produce no errors when it fails to produce debug information.

It will display diagnostic information only after the file is modified again. Is this intended behavior? If so, could there be a flag to force the re-generation of diagnostic information for the crate?

(Imgur link https://imgur.com/a/bohAtqk)

Version: cargo 1.27.0-nightly (9e53ac6 2018-05-07)

[ehuss]

If you only have warnings, then due to caching it will not re-check your package. This has been brought up a few times (see #3624, #5236, #5455).

[mooman219]

@ehuss
Ah darn, thanks for the references. To clarify once more before closing this issue, is this behavior intended in the long term? It sounds like I'm not the only one surprised by the statefullness of cargo check.

[ehuss]

is this behavior intended in the long term

I don't know, someone on the cargo team will have to say. It's not clear how it should behave (for example, #5236 had the opposite reaction where they were surprised when it re-ran every time). There was some discussion of caching the diagnostics, but that is not an easy task.

[alexcrichton]

I believe @ehuss's diagnosis is spot on here. I think it'd be neat to explore options here but currently we have no way of buffering rustc's output and re-rendering it as rustc intended

[bcmills]

Coming from Go, I found this behavior really surprising: I expected to be able to run watch cargo check as I code and get useful output (as I can in Go with go vet && go build), but the warnings from cargo check disappear after the first run. I can't tell whether I'm supposed to run cargo clean && cargo check (and take what I expect to be a big hit to build latency), or just very carefully avoid anything that might execute a build until I'm ready to view the results.

FWIW, in the go tool we do cache the diagnostics. It's certainly not trivial, but I wouldn't say it's particularly difficult either, and idempotent command output seems like a really important property for users to be able to layer on their own tooling on top of cargo.

As a user, I don't want to have to think about whether some tool I just ran (for example, an IDE hook) also happened to eat my build warnings as a side-effect.

[NickeZ]

This behavior works really bad with vim/neomake which has options to run cargo check when you open a buffer / while editing and when saving a buffer. The stateful behavior of cargo check makes some warnings disappear even if they aren't fixed.

my workaround for now is to only enable cargo check on file write. But this is clearly a worse experience than writing in other languages where it updates live.

[mooman219]

This sounds bad, but my workaround involved automating the deletion of .rmeta under /target/debug before I ran cargo check. This didn't add any discernible amount time to compilation. I don't believe this works anymore but I'm fixed on an older version of rust right now.

[richardmatheson]

This is causing a lot of frustration for our team - A lot of warnings have been missed because people forget and the compiler doesn't warn them if they haven't touched that code. The workaround is easy, but people don't want to do that before every build. A flag (--full or --rebuild or something similar) which rebuilds everything would be a start. for now.

[ehuss]

This has been implemented, closing in favor of the tracking issue #6986 which people can follow for the path to stabilization.