Post-monomorphization errors traces MVP

[lqd]

This PR works towards better diagnostics for the errors encountered in #85155 and similar.

We can encounter post-monomorphization errors (PMEs) when collecting mono items. The current diagnostics are confusing for these cases when they happen in a dependency (but are acceptable when they happen in the local crate).

These kinds of errors will be more likely now that stdarch uses const generics for its intrinsics' immediate arguments, and validates these const arguments with a mechanism that triggers such PMEs.

(Not to mention that the errors happen during codegen, so only when building code that actually uses these code paths. Check builds don't trigger them, neither does unused code)

So in this PR, we detect these kinds of errors during the mono item graph walk: if any error happens while collecting a node or its neighbors, we print a diagnostic about the current collection step, so that the user has at least some context of which erroneous code and dependency triggered the error.

The diagnostics for issue #85155 now have this note showing the source of the erroneous const argument:

note: the above error was encountered while instantiating `fn std::arch::x86_64::_mm_blend_ps::<51_i32>`
  --> issue-85155.rs:11:24
   |
11 |         let _blended = _mm_blend_ps(a, b, 0x33);
   |                        ^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

Note that #85155 is a reduced version of a case happening in the wild, to indirect users of the rustfft crate, as seen in ejmahler/RustFFT#74. The crate had a few of these out-of-range immediates. Here's how the diagnostics in this PR would have looked on one of its examples before it was fixed:

error[E0080]: evaluation of constant value failed
 --> ./stdarch/crates/core_arch/src/macros.rs:8:9
  |
8 |         assert!(IMM >= MIN && IMM <= MAX, "IMM value not in expected range");
  |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the evaluated program panicked at 'IMM value not in expected range', ./stdarch/crates/core_arch/src/macros.rs:8:9
  |
  = note: this error originates in the macro `$crate::panic::panic_2015` (in Nightly builds, run with -Z macro-backtrace for more info)

note: the above error was encountered while instantiating `fn _mm_blend_ps::<51_i32>`
    --> /tmp/RustFFT/src/avx/avx_vector.rs:1314:23
     |
1314 |         let blended = _mm_blend_ps(rows[0], rows[2], 0x33);
     |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

note: the above error was encountered while instantiating `fn _mm_permute_pd::<5_i32>`
    --> /tmp/RustFFT/src/avx/avx_vector.rs:1859:9
     |
1859 |         _mm_permute_pd(self, 0x05)
     |         ^^^^^^^^^^^^^^^^^^^^^^^^^^

note: the above error was encountered while instantiating `fn _mm_permute_pd::<15_i32>`
    --> /tmp/RustFFT/src/avx/avx_vector.rs:1863:32
     |
1863 |         (_mm_movedup_pd(self), _mm_permute_pd(self, 0x0F))
     |                                ^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0080`.
error: could not compile `rustfft`

To learn more, run the command again with --verbose.

I've developed and discussed this with them, so maybe r? @oli-obk -- but feel free to redirect to someone else of course.

(I'm not sure we can say that this PR definitely closes issue 85155, as it's still unclear exactly which diagnostics and information would be interesting to report in such cases -- and we've discussed printing backtraces before. I have prototypes of some complete and therefore noisy backtraces I showed Oli, but we decided to not include them in this PR for now)

[samlh]

I found the message somewhat opaque - maybe change the text to something like this?

note: error found while monomorphizing this function call

Even better would be to avoid having to mention monomorphization entirely.

[oli-obk]

We could rewrite the message as the above error was encountered while instantiating generic thing X with concrete parameters A, B and C

[lqd]

The people have spoken! I've removed "monomorphization" (post-, or otherwise) from the diagnostic note, to be closer to Oli's suggestion (with the erroneous item and its substs, like the other MonoItems are usually displayed).

I've updated the OP to show the result on the snippet from issue 85155, and the more complete rustfft example.

[oli-obk]

@bors r+

[bors]

📌 Commit 6f61456 has been approved by oli-obk