add test for unused ill-formed constant

[RalfJung]

Once rust-lang/rust#75339 lands, this test should pass.

Fixes #1382.

[RalfJung]

@oli-obk there are some strange things going on here... first of all, this is the error Miri shows:

warning: any use of this value will cause an error
 --> tests/compile-fail/erroneous_const.rs:9:21
  |
9 |     const VOID: ! = panic!(); //~ERROR any use of this value will cause an error
  |     ----------------^^^^^^^^-
  |                     |
  |                     the evaluated program panicked at 'explicit panic', tests/compile-fail/erroneous_const.rs:9:21
  |
note: the lint level is defined here
 --> tests/compile-fail/erroneous_const.rs:5:9
  |
5 | #![warn(const_err)]
  |         ^^^^^^^^^
  = note: this warning originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info)

error: post-monomorphization error: referenced constant has errors
  --> tests/compile-fail/erroneous_const.rs:13:8
   |
13 |     if false {
   |        ^^^^^ referenced constant has errors
   |
   = note: inside `no_codegen::<i32>` at tests/compile-fail/erroneous_const.rs:13:8
note: inside `main` at tests/compile-fail/erroneous_const.rs:18:5
  --> tests/compile-fail/erroneous_const.rs:18:5
   |
18 |     no_codegen::<i32>();
   |     ^^^^^^^^^^^^^^^^^^^

Note the completely ridiculous span for "referenced constant has errors", it points at the false?!?

Second, even though we have a warning on line 9, compiletest insists that I need to make this an ERROR annotation. I forgot about our -Dwarnings in the compiletest runner.

[RalfJung]

The span happens because we do this right after pushing the stack frame, when the current MIR statement to be executed is the first statement in the first block. But of course we don't want to point at that statement, we want to point at the required const that we evaluated.

[RalfJung]

But how would we know this in generate_stacktrace? Constant comes with a span, but is this the span where the constant is used or where it is defined?

I think this is similar to why ConstProp has to explicitly pass a span to ConstEvalErr::new -- though that seems a bit strange since that should have the current statement set correctly.

[RalfJung]

I tried to follow our spans in const_eval/{eval_queries,error} and realized I do not have the slightest clue what is going on. There are so many spans overwriting each other and then sometimes being replaced again later and elsewhere we are pretty inconsistent with whether we use the span closest to the error or the outermost span of the DefId -- it's all just a huge mess...

For example, report_as_lint takes two spans (one via TyCtxtAt and one explicitly, though the latter is optional); it is entirely unclear what the role of these two spans is and different callers seem to use them inconsistently.

Also, even after lots of digging I could not figure out how we ever have more than one "primary span" in the MultiSpan of the const-err diagnostic, and yet the code report_as_lint clearly shows that this is what happens (or is that dead code?).

Lucky enough none of this matters for Miri error reporting^^ but still, it's quite the chaos.

[oli-obk]

Constant comes with a span, but is this the span where the constant is used or where it is defined?

where it is used. This is the span that should be used for linting about failed evaluation of a constant

[RalfJung]

@bors r+

[bors]

📌 Commit 925d607 has been approved by RalfJung

[bors]

⌛ Testing commit 925d607 with merge 1bfb26d...

[bors]

☀️ Test successful - checks-travis, status-appveyor
Approved by: RalfJung
Pushing 1bfb26d to master...