An associated type magically adds a destructor?

[alevy]

These two code snippets should functionally be doing the same thing, but the type checker seems to think one has a destructor. The difference seems to be in the reliance on an associated type.

rustc complains that myfoo cannot be declared a mutable static because it has a desctructor:

pub trait Foo {
    type FooAssoc;
}

pub struct Bar<F: Foo> {
    id: F::FooAssoc
}

pub struct Baz;

impl Foo for Baz {
    type FooAssoc = usize;
}

static mut myfoo : Bar<Baz> = Bar { id: 0 };

While this, unsurprisingly, works:

pub struct Bar<A> {
    id: A
}

static mut myfoo : Bar<usize> = Bar { id: 0 };

Here are links to non-compiling/compiling examples on play.rust-lang:

• non-working: http://is.gd/BVUqfJ
• working: http://is.gd/lWbhzw

[nikomatsakis]

(@alevy expressed interest in working on this, I will mentor.)

[bstrie]

Triage: still relevant.

[alevy]

I'm still interested in helping to fix this. @nikomatsakis you mentioned at one point that you had a hunch for where the problem was. Perhaps a pointer would be enough to get the ball rolling?

[nikomatsakis]

@alevy Hmm. So, the error is emitted by the "constant qualification" code, which walks the MIR for generating a constant value and looks for things that should be disallowed. One of those things is the creation of a struct which has a destructor.

This code is in src/librustc_mir/transform/qualify_consts.rs. I think where I would start is trying to insert some debug! to track out exactly what is happening. My guess would be that we are walking down this branch, but I'm actually not sure.

cc @eddyb, author of the code in question

[eddyb]

It might be the type contents, if we use them for "needs drop". Aren't they conservative wrt projections?

[nikomatsakis]

@eddyb that was my first assumption, that it was something like that. When I was poking about in the code I didn't see the place where we branch into that, but maybe I just wasn't reading very carefully.

[eddyb]

Qualif::restrict calls into TyCtxt::type_needs_drop_given_env which references #22815.
cc @pnkfelix This could at least try to normalize projections, which would fix the problem here.
Btw we can now remove "type contents" and replace it with two cached flags (UnsafeCell & needs-drop).

[ObsidianMinor]

This doesn't seem to be an issue anymore. Running the provided "non-working" code doesn't trigger a compiler error.

[alevy]

Indeed, this not longer seems to be an issue. Happy to close the issue :)

[bstrie]

Should we add a regression test first?