add #[non_owned] and #[mutable] attributes

[thestinger]

Also fixed the docstring on TC_ONCE_CLOSURE (was accidentally the same as TC_MUTABLE) and shifted the TC_EMPTY_ENUM bit left by one since whatever previously used that bit has been removed.

[brson]

What is the effect of being #[non_owned]? Does a struct being non-owned impact which heap is used to allocate a ~? If a non-owned struct allocated in a ~ actually uses the local heap then that will invoke the GC, defeating the purpose of using non-owned smart pointers.

I am still not clear on the impact of non-owned. Is there consensus on how this is supposed to work? I am worried that there are a lot of 'cracks' in the type system and things are not fitting together as well as they should.

[thestinger]

@brson: I think the effect of not being Owned is just that it's non-sendable. A struct containing borrowed pointers isn't Owned so it definitely shouldn't be used as the deciding factor for local heap allocation (TC_MANAGED would make more sense for that AFAIK).

[pcwalton]

I think I'd prefer #[unsafe_mutable] to #[mutable] — people are going to add #[mutable] to their structs and wonder why they aren't mutable. I'm OK with that being done in a followup though.

[thestinger]

@pcwalton: maybe #[non_const] to go along with #[non_owned], since const will only be used for the Const trait. I was actually going to call it that originally but I went with mutable when I realized I didn't have to add TC_NON_CONST - but that's not really a good reason :).

[sanxiyn]

CC #5601.