Don't emit the same compiler diagnostic twice. #45519
Conversation
|
r? @arielb1 (rust_highfive has picked a reviewer for you, use r? to override) |
|
To clarify what motivates this PR: With incremental compilation there are cases where we emit diagnostics that we have cached from the previous compilation session. It then sometimes occurs that we have to recompute a value (because we have not cached it) but cannot decide for sure if we should re-emit diagnostics during this re-computation. This PR solves the problem by having a global filter that just remembers all diagnostics that have already been emitted. |
kennytm
added
the
S-waiting-on-review
|
So this is only needed when anonymous nodes (today trait selection) can emit warnings? Trait selection is already called very unpredictably, so emitting warnings from there is a good way to spam the user. I think that every place we want to use anonymous nodes in is going to be evaluated unpredictably (because we can't come with a good set of dep-nodes that should all be evaluated) and therefore would not be a good place to emit warnings from. |
|
It also solves #34229 and makes the implementation of this deduplication logic cleaner. |
|
That's a hacky but ok way of dealing with the derive problem |
|
📌 Commit 9736474 has been approved by |
kennytm
added
S-waiting-on-bors
Don't emit the same compiler diagnostic twice. This PR makes the compiler filter out diagnostic messages that have already been emitted during the same compilation session.
|
☀️ Test successful - status-appveyor, status-travis |
…omatsakis incr.comp.: Implement compiler diagnostic persistence. This PR implements storing and loading diagnostics that the compiler generates and thus allows for emitting warnings during incremental compilation without actually re-evaluating the thing the warning originally came from. It also lays some groundwork for storing and loading type information and MIR in the incr. comp. cache. ~~It is still work in progress:~~ - ~~There's still some documentation to be added.~~ - ~~The way anonymous queries are handled might lead to duplicated emissions of warnings. Not sure if there is a better way or how frequent such duplication would be in practice.~~ Diagnostic message duplication is addressed separately in #45519. r? @nikomatsakis
|
Hmm, after this PR the error count is wrong. For example, the code in #34229 stops after three unique errors, but says "aborting due to 9 previous errors". |
This PR makes the compiler filter out diagnostic messages that have already been emitted during the same compilation session.