ICE when a static variable is declared of type for which the `Drop` trait is implemented

[MarkJr94]

Minimal test case:

struct Test {
    mem: int,
}

pub static g_test: Test = Test {
    mem: 0,
};

impl Drop for Test {
    fn drop(&self) {
    }
}

fn main() {

}

Resulting Error after run with RUST_LOG=rustc=1 rustc test.rs:

task <unnamed> failed at 'assertion failed: `(left == right) && (right == left)` (left: `1u`, right: `2u`)', /build/buildd/rust-nightly-201309160805~3fbfab0~raring/src/librustc/middle/trans/adt.rs:545
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug
note: try running with RUST_LOG=rustc=1 to get further details and report the results to github.com/mozilla/rust/issues
task <unnamed> failed at 'explicit failure', /build/buildd/rust-nightly-201309160805~3fbfab0~raring/src/librustc/rustc.rs:377

Also, this:

struct Test;

pub static g_test: Test = Test;

impl Drop for Test {
    fn drop(&self) {
    }
}

fn main() {

}

compiles just fine, although I believe both cases should give a compilation error about having static variable implementing the Drop trait.

My rustc is acquired form the rust-nightly package in the Ubuntu repo.

Output of rustc --version:

rustc 0.8-pre
host: x86_64-unknown-linux-gnu

[alexcrichton]

Nominating the decision of whether to allow this for the well-defined milestone

[luqmana]

This also raises the question about whether to even allow putting types with destructors in a static? When would they run?

[catamorphism]

accepted for well-defined

[alchemy]

Static items of a type implementing the Drop trait can have their distructors called at program termination, as in C++. Thus, both test cases above should compile without errors.

[brson]

@alchemy it's not clear what the semantics of running destructors at program termination would be since at program termination there are no tasks in which to run the destructor.

I'd say to just forbid types that implement Drop in statics, but that doesn't seem sufficient. What about mutable statics that contain objects (or closures) that might implement Drop? What about mutable types that contain allocations? Are we happy just letting them leak at termination?

[alexcrichton]

We decided in the 10/15/13 meeting to disallow static items which have destructors (things like ~T or those with the Drop trait implemented).

[alchemy]

Wise decision, i have been a little too hasty in my previous comment.
As for the questions raised by @brson: as i see it, the only remaining issue is about managed allocations and potential memory leaks at program termination (as there is no task local gc). I'd say to leave things as they are. The compiler already forbids the @ operator in constant expressions, so the only way for allocations to end up in a (mutable) static item is through unsafe code, which seems reasonable.
The alternative is to disallow static items containing managed pointers altogether.

[Aatch]

With the new Pod kind incoming, would making the rule be that statics have to be Pod be acceptable? I think that it's technically a bit more limiting, but probably not enough to matter. It should also prevent any other future odd edge cases.

[nrc]

still ICEs, looking into this

[huonw]

@nick29581 this seems very likely to be covered by #11979.

[nrc]

Thanks huonw, I knew there was another issue similar to this because we discussed it at the meeting, but I couldn't find the number.

@flaper87 - will this get fixed by #11979?

[nikomatsakis]

Closing as dup of #11979 -- under the rules we've discussed there, both of these programs would be in error (no static value may have a destructor).