<p dir="auto">This may be a duplicate, but can't find the original if it exists.</p>
<p dir="auto">See <a href="http://doc.rust-lang.org/core/intrinsics/index.html" rel="nofollow">http://doc.rust-lang.org/core/intrinsics/index.html</a> for the problem. Most of the intrinsics are doc'd with stability markers, but none of that shows up. Docs also consequently don't show up in re-exports.</p>
<p dir="auto">There are many situations in which we wind up reporting duplicate errors during trait matching and elsewhere. You can see this in many of the compile-fail tests which wind up with the same error several times. These messages often arise naturally because multiple parts of the code give rise to the same obligation, and because of type inference, which can make it hard to tell whether two trait obligations are in fact the same until it is too late. (In fact, we already silently drop two EXACT DUPLICATE obligations for various other reasons).</p>
<p dir="auto">I think the best thing is just to add some sort of hashset and check for duplicates in <code class="notranslate">librustc::middle::traits::error_reporting</code> or maybe <code class="notranslate">librustc_typeck::check::vtable</code>. But we should do this check <em>after</em> doing full type resolution.</p>
<p dir="auto">I am not sure whether to consider the spans. On the one hand, getting the same error for every line where it occurs is useful, and it can be confusing if you get an error from line A but not B even though they seem identical. This may lead you to think that B is somehow ok, when in fact the compiler was just helpfully suppressing a duplicate error. On the other hand, we already some amount of suppression like that, so the situation above can already arise, and perhaps being more consistent would wind up being less confusing overall.</p>