Invoking TLD on task destruction yields an opaque error message

[alexcrichton]

local_data_key!(foo: Foo)

struct Foo;

impl Drop for Foo {
    fn drop(&mut self) {
        foo.replace(Some(Foo));
    }
}

fn main() {
    foo.replace(Some(Foo));
}

error:

failed at 'must have a local task to insert into TLD', /Users/rustbuild/src/rust-buildbot/slave/nightly-mac/build/src/librustrt/local_data.rs:159
run with `RUST_BACKTRACE=1` to see a backtrace

You've met with a terrible fate, haven't you?

fatal runtime error: Could not unwind stack, error = 5
zsh: illegal hardware instruction  ./foo

I believe we should take a more principled approach to this:

1. take() the local task's TLD map.
2. Drop the TLD map. If this re-invokes TLD, the missing TLD map in the task will be re-initialized.
3. Repeat steps 1-2 a fixed number of times while the map was re-initialized.
4. Abort with a nice error message if the map is still initialized. Otherwise continue invoking GC destructors.

Nominating, but I don't believe this blocks 1.0

[pnkfelix]

Assigning P-low, not blocking 1.0.

[steveklabnik]

Okay, so this API has changed significantly, but I think this is it:

thread_local!(static foo: Foo = Foo);

struct Foo;

impl Drop for Foo {
    fn drop(&mut self) {
        foo.with(|f| {
        });
    }
}

fn main() {
    let f = Foo;
}

yields

thread '<main>' panicked at 'cannot access a TLS value during or after it is destroyed', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/option.rs:330
fatal runtime error: Could not unwind stack, error = 5
/bin/bash: line 1: 14786 Illegal instruction     ./hello

that error seems much more clear. And its documentation says

This function will panic!() if the key currently has its destructor running,

So I'd consider this closed. What do you think, @alexcrichton

[alexcrichton]

I agree!