Refactor away the TypeckTables::cast_kinds field

[oli-obk]

Motivation

This field has a lot of code going into creating it, while its use sites barely care at all about all the nice data it contains. They could just as well compute the data they need themselves. Computing the data is cheap, so there's no point in computing this ahead of time.

Instructions

1. Eliminate uses

The field is used in two places:

1. HIR -> MIR conversion

   rust/src/librustc_mir/hair/cx/expr.rs

   Line 590 in 50702b2

   if let Some(&TyCastKind::CoercionCast) = cx.tables()

2. rvalue promotion

   rust/src/librustc_passes/rvalue_promotion.rs

   Line 371 in 50702b2

   match v.tables.cast_kinds().get(from.hir_id) {

The 1. use can be fixed by just checking whether the type of source is the same type as expr_ty. This means all foo as Bar casts get ignored if foo is already of type Bar. Which is exactly what that code is trying to do.

The 2. use actually wants to know the cast kind, but there's no need to get that from the cast_kinds field. Instead one would again obtain the type of the expression being cast and the type being cast to, and then do exactly what MIR based borrowck does when going through the same code (Use CastTy to figure out the details):

rust/src/librustc_mir/transform/qualify_consts.rs

Lines 719 to 725 in 38168a7

	Rvalue::Cast(CastKind::Misc, ref operand, cast_ty) => {
	let operand_ty = operand.ty(self.mir, self.tcx);
	let cast_in = CastTy::from_ty(operand_ty).expect("bad input type for cast");
	let cast_out = CastTy::from_ty(cast_ty).expect("bad output type for cast");
	match (cast_in, cast_out) {
	(CastTy::Ptr(_), CastTy::Int(_)) |
	(CastTy::FnPtr, CastTy::Int(_)) => {

2. Eliminate the field and all the code feeding into it

This part is easy now. Remove the field, and the compiler will guide you to all the places it's used. All you have to do is remove code until the compiler is happy.

[eddyb]

cc @nikomatsakis @arielb1

[cjkenn]

I'd like to take a look at this. I should be able to get a pr in a few days (possibly with a few questions -_-)

[oli-obk]

@cjkenn awesome! Don't hesitate to ask here or on irc/discord if you have any questions

[arielb1]

@oli-obk

The reason I wanted to detect CoercionCast in typeck was because the types on both sides of the cast could be subtypes but not equal (e.g. converting a for<'a> dyn Trait<'a> to a Trait<'s>).

However, I think we can do a subtype check in hair these days, so this is a non-problem.

[cjkenn]

@oli-obk For case 1, do we intend to do something like this:

let source_ty = cx.tables().expr_ty(source);
if source_ty == expr_ty {
    // Convert the lexpr to a vexpr.
    ExprKind::Use { source: source.to_ref() }
else {
...

I'm unsure if this results in the same behaviour as the current code

[oli-obk]

Oh right. So basically Rptr -> Rptr casts, Rptr -> Ptr casts and any cast where the types are equal. I think that are the only coercions?

[eddyb]

@arielb1 However, if it's a coercion cast, doesn't the coercion happen on top of the unadjusted type? I guess I'm not sure where the coercion is exactly... I'm guessing on the source expression?

[matthew-russo]

@cjkenn @oli-obk Is this still being actively worked on?

[arielb1]

@eddyb

@arielb1 However, if it's a coercion cast, doesn't the coercion happen on top of the unadjusted type? I guess I'm not sure where the coercion is exactly... I'm guessing on the source expression?

Yea, but if you have a no-op coercion (i.e. "just a subtyping conversion"), the adjusted type of the source expression can be the same as the type of the source expression, and a supertype of the type of the destination expression.

[cjkenn]

@mcr431 I haven't worked on this at all really :( I'm unsure what to do, and if this is something we can/want to do.

[ZerothLaw]

Is this work still needed? Will it conflict with Chalkification?

[saleemjaffer]

@oli-obk I would like to take a shot at this :) I am a newbie to rust.

[oli-obk]

sure! The instructions in the main issue should still apply, even if the exact locations of the code may have changed

[saleemjaffer]

@oli-obk
For 1. I do something like this but keep gettting a thread 'rustc' panicked at 'bad input type for cast', src/libcore/option.rs:1038:5d. I am stuck at this. Any help?

        hir::ExprKind::Cast(ref source, ref cast_ty) => {
            // Check for a user-given type annotation on this `cast`
            let user_provided_types = cx.tables.user_provided_types();
            let user_ty = user_provided_types.get(cast_ty.hir_id);

            debug!(
                "cast({:?}) has ty w/ hir_id {:?} and user provided ty {:?}",
                expr,
                cast_ty.hir_id,
                user_ty,
            );
            
            let source_ty = cx.tables().expr_ty(source);
            let cast = if source_ty == expr_ty {
                // Convert the lexpr to a vexpr.
                ExprKind::Use { source: source.to_ref() }
            } 

[oli-obk]

Do you have a backtrace of that panic?

I think it would be easier to review if you open a PR with your changes and we'll discuss the problems there. Basically just a single PR for the 1.