Fix post-monomorphization error note race in the parallel frontend

[xmakro]

Fixes #154260. Part of #154314.

collect_items_rec decides whether to attach the note "the above error was encountered while instantiating fn ..." by snapshotting the error count before processing a mono item and comparing it afterwards. The mono item graph is walked in parallel (the par_for_each_in in collect_crate_mono_items), so the global error count can be bumped by an error emitted while collecting a different item on another thread between the two reads. That makes an unrelated item get blamed, which showed up as a spurious note when using parallel frontend:

note: the above error was encountered while instantiating `fn std::rt::lang_start::<()>`

This PR records the thread that emits each error alongside its ErrorGuaranteed in err_guars, lint_err_guars, and the stashed-diagnostics map, and add err_count_on_current_thread, which counts only the errors whose recorded thread is the calling thread. The collector uses it for the snapshot and comparison, so the delta is not affected by errors emitted on other threads. In serial compilation it is equivalent to a delta of err_count.

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @mejrs (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: compiler
• compiler expanded to 73 candidates
• Random selection from 18 candidates

[mejrs]

r? @petrochenkov

[zetanumbers]

This method is misleading since instead of modifying the self argument it actually modifies a thread local. Instead we could store a ThreadId in the err_guars, lint_err_guars and stashed_diagnostics fields so that err_count_on_current_thread could filter and count errors almost like the old err_count, but also counting only matching ThreadIds.

View changes since the review

[zetanumbers]

TBH we could use any type for this CountErrorsId as long as we set it in compiler/rustc_monomorphize/src/errors.rs and it is implicitly "passed down" to through the callstack, in a thread local for example.

[xmakro]

Thanks, I added the ThreadId explicitly to the relevant vecs holding errors, do you prefer type ErrCountId = ThreadId?

[zetanumbers]

Please no type alias. This is fine.

[xmakro]

Thanks, addressed