Disallow non-monomorphic calls to needs_drop in interpreter

[tmiasko]

otherwise evaluation could change after further substitutions.

[rust-highfive]

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

[rust-highfive]

r? @varkor

(rust-highfive has picked a reviewer for you, use r? to override)

[RalfJung]

Thanks, this makes sense.
Is there any reason not to do this for all eval_nullary_intrinsic?

[RalfJung]

Cc @oli-obk

[tmiasko]

Is there any reason not to do this for all eval_nullary_intrinsic?

I could be useful for optimizations to evaluate variant_count::<Option<T>>() or needs_drop::<ManuallyDrop<T>>() as soon as possible.

I do have a test case, but wasn't sure if we want one that depends on const_evaluatable_unchecked; following compiles on nightly:

#![feature(const_generics)]

struct Value<const B: bool> {}
impl Value<true> { fn is_true() {} }

fn f<T>() {
    Value::<{std::mem::needs_drop::<T>()}>::is_true();
}
fn main() {
    f::<u32>();
}

[RalfJung]

I could be useful for optimizations to evaluate variant_count::<Option>() or needs_drop::<ManuallyDrop>() as soon as possible.

Well, for the latter that won't happen any more with this PR, right?
If we want this, we need a needs_drop inside rustc that can answer "yes", "no", and "don't know".

[tmiasko]

Well, for the latter that won't happen any more with this PR, right?

For variant_count we already have suitable implementation, for needs_drop we would need to change it.

[RalfJung]

Ah, fair.

Then maybe add comments to the other branches (the ones that do not call "ensure_monomorphic") explicitly saying "this code will correctly handle non-monomorphic calls" or so. I want to make sure that when/if another intrinsic is added, we don't introduce the same bug again...

[varkor]

r? @RalfJung

[RalfJung]

Code change looks good to me; is there any way to have a test for this? r=me otherwise.

[tmiasko]

Added a test case mentioned earlier.

[RalfJung]

Awesome, thanks a lot. :)
@bors r+

[bors]

📌 Commit 07a03b0 has been approved by RalfJung

[Aaron1011]

This error is useless - it would be good to suppress it. Is there already an issue for this kind of error?

[bors]

⌛ Testing commit 07a03b0 with merge 66ba810...

[bors]

☀️ Test successful - checks-actions
Approved by: RalfJung
Pushing 66ba810 to master...