ty::type_contents is too imprecise in some cases (e.g. when called from trans)

[pnkfelix]

spawned off of #22536

@nikomatsakis tells me that trans has been migrating away from its uses of ty::type_contents (or perhaps he meant that rustc in general is migrating away from using it). But there are still places that rely on it to drive particular bits of logic.

This is problematic because ty::type_contents is designed to produce a set of properties that could hold for the given type, depending on what is substituted for its type parameters; this is in stark contrast to trans, which deals directly with a monomorphized (and normalized type), where all of the relevant information needed for codegen is readily available.

• One might think that there is apparently no problem here at all: surely a monomorphized and normalized type has no free type parameters, and thus the question of substitutions is irrelevant?
• Unfortunately, the way that ty::type_contents is written, it is relevant, because when you compute the type contents of a struct instance like BufferHandle<Res>, the logic of ty::type_contents recursively processes its fields (after substitution), namely the type <Res as Resources>::Buffer. But at this point, type contents just says "That's a projection; anything could be substituted in for that", and produces the most conservative result (a bitset holding all ones for the type-contents). And then that conservative result pollutes the type-contents for the whole BufferHandle<Res> overall.
• The specific line here regarding the "That's a projection; ..." is here in ty::ty_contents.

I am going to try to fix the actual unsoundness that results from the problems above by avoiding relying on ty::type_contents as anything but an conservative approxmation within trans.

This ticket is to log the cases (in e.g. trans, but potentially also elsewhere) where there still are calls to ty:type_contents, so that we can go back and replace them with something better. (E.g., perhaps a new version of type contents has the inputs it needs to normalize types as it descends through their structure, which ty::type_contents does not currently have.)

My hope is that the cases listed on this ticket do not reflect cases where we have unsound behavior, but merely cases where we can in some cases produce lower quality code than we would otherwise.

• Update: This description was originally written in the context of a use of ty::type_contents from trans, but pnkfelix hypothesized based on Send/Sync transitive analysis lost in stored associated types #22828 that the same problem affects other parts of the compiler true, resulting not merely in lower quality code, but also ... "expressiveness exceptions." (Better term, anyone?)

---

Footnote: In the concrete example of #22536, the particular issue is that the decision about whether to zero the original memory after copying-or-moving a value from one place to another is based on looking up the "needs_drop" bit in the type contents. Since the type contents is all-ones, we are meant to conclude "I guess this value might have an associated destructor." Of course, this is very wrong in the case of trans, where given "this might have an associated destructor", it is very wrong to conclude "I must need to zero the original memory where I got the value." We can (and I will) fix the particular issue of #22536 on its own. But I want to file this ticket first so that I have an issue number to put into comments near the uses of ty:type_contents that remain.

[pnkfelix]

The specific line here regarding the "That's a projection; ..." is here in ty::ty_contents

Note that if we normalized the input as ty::type_contents traversed it, then this scenario would play out differently; presumably in that case we would see the specific concrete type Res involved in Res as Resources>::Buffer (rather than the type parameter R), and thus be able to look up the specific Buffer type associated with Res. So that scenario ty::type_contents would produce precise results.

[alexcrichton]

Closed #22828 in favor of this, but just a reminder to ensure this compiles if this issue is closed:

trait Foo {
    type A;
    fn foo(&self) {}
}

impl Foo for usize {
    type A = usize;
}

struct Bar<T: Foo> { inner: T::A }

fn is_send<T: Send>() {}

fn main() {
    is_send::<Bar<usize>>();
}

(current error)

foo.rs:15:5: 15:26 error: the trait `core::marker::Send` is not implemented for the type `<usize as Foo>::A` [E0277]
foo.rs:15     is_send::<Bar<usize>>();
              ^~~~~~~~~~~~~~~~~~~~~
foo.rs:15:5: 15:26 note: `<usize as Foo>::A` cannot be sent between threads safely
foo.rs:15     is_send::<Bar<usize>>();
              ^~~~~~~~~~~~~~~~~~~~~
error: aborting due to previous error

[steveklabnik]

Triage: @alexcrichton 's example now compiles. Can this be closed?

[nikomatsakis]

It seems like we only use type_contents in trans for optimization purposes now....so maybe still relevant, but much less so.

[Mark-Simulacrum]

I believe @eddyb replaced/moved type_contents in 9ad3b94 so this is possibly closeable? Not sure.