atomic intrinsics should take unsafe pointers not borrowed pointers

[brson]

These are very unsafe operations. We should not be pretending that they operate on safe pointers.

[mnemotic]

@brson I'd like to take a stab at this.

[Aatch]

@mnemotic I did most of the current work on atomics. This change should just require changing typeck/mod.rs to use raw pointers instead of region pointers. You'll also need to update the intrinsics in unstable/intrinsics.rs

Finally, if your willing, I have a few issues open for finishing the atomic support, this just means adding the rest of the operations to the types in unstable/atomics.rs.

I'm aatch on IRC too, so hit me up if you have any questions.

[mnemotic]

@Aatch Thanks for the support. Re: other issues; I've looked at #7421 and #7422. Are there others? I mean to look into those after I tackle this, but I'm not committing to it (yet).

[bblum]

I think I disagree with this. There's nothing about atomic ops that break the type system; they are only dangerous in conjunction with unsafe-shared-mutable-state. So you'll already have to have unsafe blocks if you're doing unsafe atomic ops.

[auroranockert]

@bblum But what are the use-cases for atomics without shared mutable state? Couldn't you just use normal integers then?

[bblum]

It is true that they are not good for much when used in otherwise-safe code. But that doesn't make them unsafe in their own right. Sort of like how creating a *T is fine, but dereferencing it is unsafe.

I suppose they are just the intrinsics, not the interface of the unstable::atomics library, so it does not matter as much as I initially thought, since pretty much nobody except unstable::atomics should be using them directly.

[bblum]

Think about it like this: An operation is unsafe iff the compiler cannot verify that an arbitrary use of the operation will not break type safety or memory safety. If we can reason about the operation to the extent that we're sure that no use of it will crash, there's no reason for it to be unsafe.

[emberian]

I actually agree with bblum here. There's no reason to make atomic ops unsafe if you already need unsafe code to do unsafe things with them. They're perfectly safe and well-defined.

[pnkfelix]

Nominating for P-backcompat-libs.

[pnkfelix]

brson pointed out to me that the intrinsics are not part of the backcompat api, so this never would be P-backcompat-foo.

At this point brson also thinks that we do not need to change to *T; the arguments here for leaving as is have convinced him that this bug can be closed.