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.

[flaper87]

Quick update on this issue: The restriction for static items with Drop implementations has been added. In order to move that work forward, it's necessary to find a better way to tag NonCopyable types. @nikomatsakis alreay has a PR for this. As soon as the PR is proposed, I'll based the above commit on that PR.

[nikomatsakis]

On Wed, Jan 22, 2014 at 02:42:08PM -0800, Flavio Percoco Premoli wrote:

@nikomatsakis alreay has a PR for this

#11768

[nikomatsakis]

Still weighing what I think is best path. The necessity of modifying trans is a drag, although it's temporary. But it feels like constants like DUMMY_SP etc are nice to be able to do.

[alexcrichton]

In theory, if we had a Cell or RefCell static constructor you could have a static that you could leak memory into. That being said, both of those structures are implemented with unsafe code, so perhaps part of the safe interface is just not providing static constructors.

Having two separate sets of rules seems a little odd though. I'd almost prefer to start with the more restrictive path and then loosen it later if necessary.

[nikomatsakis]

You cannot create a Cell or RefCell because, to do so, you must invoke Cell::new() etc, which is not permitted in the static patterns. Still, a good point to be careful of. We could add a rule that you cannot create a value that is not Freeze.

[nikomatsakis]

Oh, I see you wrote "if we had a Cell or RefCell static constructor". I missed that at first. Yes, if you had one of those, it'd be bad (actually Cell would be ok, since Cell types must be POD, but ...).

[alexcrichton]

I've grown to like that static values must have no destructors and the type must be Freeze, and static mut types must have no destructors and.

[alexcrichton]

This was discussed in today's meeting. We agreed on what Niko commented