Don't emit the same compiler diagnostic twice.

[michaelwoerister]

This PR makes the compiler filter out diagnostic messages that have already been emitted during the same compilation session.

[rust-highfive]

r? @arielb1

(rust_highfive has picked a reviewer for you, use r? to override)

[michaelwoerister]

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.

[arielb1]

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.

[michaelwoerister]

It also solves #34229 and makes the implementation of this deduplication logic cleaner.

[arielb1]

That's a hacky but ok way of dealing with the derive problem
@bors r+

[bors]

📌 Commit 9736474 has been approved by arielb1

[bors]

⌛️ Testing commit 9736474 with merge b218a02...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: arielb1
Pushing b218a02 to master...

[durka]

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".