Miri: dispatch first on the type

[RalfJung]

Based on the fact that Miri now always has intptrcast available, we can change binops and casts to first check the type of the source operand and then decide based on that what to do, instead of considering the value (pointer vs bits) first.

[rust-highfive]

r? @estebank

(rust_highfive has picked a reviewer for you, use r? to override)

[RalfJung]

r? @oli-obk @eddyb

[RalfJung]

The Miri side of this is at rust-lang/miri#856. I verified that the test suite passes.

[oli-obk]

Just some nits

[RalfJung]

Actually, the PR as-is makes this fail:

const X2: bool = unsafe { 42 as *const i32 == 43 as *const i32 };

The reason is that == on pointer types now always errors, whereas previously it worked if both operands had integer value.

I suppose this is something we have to keep working, for backwards compatibility?

[RalfJung]

If we do want this, I think the cleanest way would be to move https://github.com/rust-lang/miri/blob/5a9ea5d1b61a860b95916366b17cce8349450332/src/operator.rs#L52-L78 into the engine. It will still fail in CTFE if either input is a pointer because force_bits will fail.

What do you think?

[oli-obk]

No, just break it. Pointer comparisons are unstable at the type level for a reason

[RalfJung]

@oli-obk I think I took care of your nits. I also had to update some test files and rebase. Please check.

[Centril]

nits

[RalfJung]

Now that's surprising, why does this affect mir-opt...

[RalfJung]

Turns out const_prop was doing ptr-to-int casts based on CTFE doing that. With CTFE not doing that any more, const_prop cannot do it any more, either.

Cc @wesleywiser

[oli-obk]

@bors r+

[bors]

📌 Commit d7b9bbf has been approved by oli-obk

[RalfJung]

Rebased.

@bors r=oli-obk

[bors]

📌 Commit b9db95e has been approved by oli-obk

[bors]

⌛ Testing commit b9db95e with merge 8e917f4...

[bors]

☀️ Test successful - checks-azure
Approved by: oli-obk
Pushing 8e917f4 to master...