I haven’t used Rust in a while and am now coming back to it. One thing that I"m noticing that I feel like wasn’t there before is that warnings are now only shown one time, and not shown again until that unit has to be recompiled.

For example, if I make a code change and cargo test I’ll see a warning. If I then close my terminal, open a new one and cargo test again I will no longer see the warning and have no idea what/if any occurred.

I have also experienced this with compile errors (though I can’t reproduce this at the moment) where a cargo run would run the old build of the application and not show me compile errors a 2nd time unless I manually run cargo clean && cargo build.

This is actually getting really frustrating, especially since in the IntelliJ app cargo test hides the console output for the nice test runner, which means it’s impossible for me to see my warnings without a cargo clean.

This sounds like an artifact of incremental compilation; if the code compiles (with only warnings, no errors) then it won’t need to be recompiled unless something has changed, and thus the warnings won’t be repeated.

It should not happen for anything with errors that prevent a successful compilation, though. If you do manage to reproduce that, it’s a bug.

For IDE integration, the RLS will publish these warnings and update them as the code is changed.

To produce warnings, the compile has to compile your code. If the build is fresh, the code isn’t recompiled; it’s already been built.

Sure but maybe there’s value in Cargo caching the warnings so they can be replayed if compile of that module is skipped? Surely I’m not the only one, and it looks like from the StackOverflow question that people are jumping through hoops to get this functionality.

It should not happen for anything with errors that prevent a successful compilation, though. If you do manage to reproduce that, it’s a bug.

fwiw I’ve had this happen several times today with a lot of frustration. At random times the compiled binary would have a last write time 3-5 minutes ahead of my system clock, which seems to be why the incremental compiler seems to ignore any and all of my changes until I cargo clean (or wait). Haven’t found a reliable way to reproduce it but I’ve had it trigger 3 times this afternoon :(.

the compiled binary would have a last write time 3-5 minutes ahead of my system clock

Well, that’s clearly a problem. Are these files on a network share, with some time offset on the server? Unless something is making your clock jump around by several minutes, I’m not sure what else could be causing this, but it clearly is going to confuse cargo and any other similar build system that resolves dependencies based on timestamps.