Attempting to move a non-copyable static segfaults

[sfackler]

fn main() {
    let x = std::unstable::atomics::INIT_ATOMIC_INT;
}

That will segfault inside of memset, preseumably because AtomicInt is non-copyable and it's trying to zero out part of .rodata.

[thestinger]

I thought we didn't allow types with a Drop implementation in a static?

[alexcrichton]

That's an interesting question. I intended the type to not have Drop implemented, but it appears that the nested NonCopyable structs inside of the atomics are causing this problem.

This will be an interesting conundrum to figure out how to make this type non-copyable but also without destructors.

[thestinger]

@alexcrichton: I could open a pull request adding a non-copyable attribute. The TypeContents code knows how to do this already for types like &mut T.

[sfackler]

I would be on board with a #[no_copy] (or whatever) attribute. It'll be consistent with #[no_freeze] and is a bit better to work with than tossing "useless" NonCopyable fields inside of structs.

[alexcrichton]

We had #[non_copyable] originally, and we removed it in favor of the NonCopyable type. I would agree that this use-case is an argument for bringing it back, however. I agree with @sfackler though in that I think the name should be #[no_copy] to align with #[no_freeze] and #[no_send].

cc @nikomatsakis and @pcwalton, you guys may have opinions on bringing back the #[no_copy].

[thestinger]

Did we really have #[non_copyable]? I don't remember it.

[nikomatsakis]

Per discussion in meeting on Jan 14, 2014:

• Enum variants should be considered rvalues, not static items
  • (requires modification to borrowck / mem categorization)
• Static items should not be permitted to have types that own things with destructors
• Moves from static items should be forbidden

[flaper87]

I'll work on this one, if that's fine!

[alexcrichton]

@flaper87, sure! This will involve adding a way to flagging a type as noncopyable without using a destructor (to allow atomics in statics (see #10834), but other than that I don't think anyone will contend with you to work on this.

Nominating, this is a backwards-compat thing for 1.0

[pnkfelix]

accepted for P-backcompat-lang

[flaper87]

@sfackler could you please update the issue report and use std::sync::atomics::INIT_ATOMIC_INT ? Atomics were pulled out of unstable.