Clean up cast categorization

[RalfJung]

Currently, our classification of casts is kind of a mess:

• We have mir::CastKind, but it has a Misc variant and most casts fall in that category (this is what ends up in the MIR).
• We also have ty::cast::CastKind that has a seemingly independent classification (no idea where this is used).
• We have a CastTy type, but can it really represent all types in a cast? If yes, I'd expect to see unwraps around here.
• In thir::ExprKind, we have Cast and Pointer expressions, the latter also being casts.

I don't know how these all relate, but it looks like some cleanup is dearly necessary here.

[JakobDegen]

ty::cast::CastKind is used by type checking and can probably be left alone. That area has its own needs anyway, especially because of diagnostics and such things.

Besides that, I've taken a look at some of the surrounding stuff. My rough guess is that the principled thing to do here would be as follows: First, stop sharing types (specifically PointerCast) between THIR/MIR and HIR. HIR has a notion of adjustments that are removed and made explicit in THIR lowering. Instead, we should add a CastKind that is used by THIR and MIR and covers all the casts that exist in those IRs. This CastKind would then replace mir::CastKind in Rvalue::Cast and we would unify thir::ExprKind::{Cast,Pointer} into one variant that also uses this CastKind.

As to what this CastKind should look like, I'm not so sure. I see two possibilities:

1. We take the current approach, which is to make it an enum that just exhaustively lists all the permitted cast categories
2. We make it a { src: CastTy, dest: CastTy } pair. This would require also making CastTy exhaustive (it currently misses some categories of types, eg FnDef). Essentially this is just giving up on enumerating the permitted set of casts in the type system, but maybe that's not so bad... clearly our current attempt to do it isn't exactly panning out.

I'm not sure who is best to ask about the viability of this plan, so cc @oli-obk I guess?

[RalfJung]

stop sharing types (specifically PointerCast) between THIR/MIR and HIR

Fully agreed.

As to what this CastKind should look like, I'm not so sure. I see two possibilities:

The source and dest type are available anyway, right? In MIR at least, the source is an operand and that always has a type. So only a destination type would be needed.

Miri indeed mostly ignores the CastKind and just looks at the pair of source and destination types. However, two kinds of casts are very different from the others and should be somehow singled out: ptr2int and int2ptr. In fact maybe they should become their own Rvalue; unlike the other casts, they are both in some sense "not pure" (ptr2int is expose_addr and has a side-effect; int2ptr is from_exposed_addr and makes a non-deterministic choice).

[oli-obk]

ptr2int and int2ptr seem like fairly ok candidates for intrinsics instead of a special MIR rvalue. I think the only thing that cares about them is const checking, and we could just not mark ptr2int as const.

[oli-obk]

I do prefer full enumeration of all casts, mostly because it keeps biting us to redo categorization everywhere.

[RalfJung]

ptr2int and int2ptr seem like fairly ok candidates for intrinsics instead of a special MIR rvalue. I think the only thing that cares about them is const checking, and we could just not mark ptr2int as const.

I would say they are great candidates for the new StatementKind::Intrinsic that keeps coming up. ;)