Tracking issue for ptr::{read,write}_volatile

[alexcrichton]

Tracking issue for rust-lang/rfcs#1467

[alexcrichton]

cc @Amanieu, would you be interested in implementing?

[Amanieu]

I'll give it a go when I find some free time, hopefully this weekend.

[oli-obk]

write_volatile can still end up triggering a llvm assertion: #29663

[alexcrichton]

🔔 This issue is now entering its cycle-long final comment period for tentative stabilization in 1.9 🔔

The libs team is comfortable with these APIs as-is, but we're pretty worried about stabilizing with the LLVM assert being a known downside. If the assert hasn't been fixed by the time the 1.9 beta release rolls around we'll likely just punt on stabilization of these APIs.

[Zoxc]

How will volatile reads/writes not supported by the platform be reported back to the user?

[nodakai]

Should T be restricted to Copy? I'm not sure

[jonas-schievink]

@nodakai ptr::read isn't restricted in that way, so my guess is no

@Zoxc ...they can be not supported? How? Or did you confuse this with atomic reads and writes?

[Amanieu]

The assert should be fixed by #32233

[Zoxc]

Hm.. it seems LLVM will implicitly split volatile operations that aren't supported. I'm not sure that is desirable semantics.

[Amanieu]

C does the same thing so I think it's fine.

[aturon]

cc @rust-lang/compiler @rust-lang/lang -- the libs team will be meeting soon to reach a stabilization decision. This API cuts across your concerns as well, so please have a look!

[huonw]

Since we don't really have a memory model/Rust abstract machine, we don't have a strong model for what volatile means (the C definition is essentially "execute exactly the operations the C abstract machine would execute"). I imagine this isn't particularly problematic in practice, but it seems like something to keep in mind.

Also, we may want to make sure the documentation doesn't tie the behaviour of these functions to LLVM's definition of volatile? (It currently refers to the LLVM docs, a reference we may want to either remove or explicitly state is non-binding.)

[alexcrichton]

The libs team discussed this during triage yesterday and the decision was to stabilize.

We discussed what the documentation would look like and we concluded that we should point to C11 instead of LLVM and also add a note saying that the memory model for Rust isn't formally defined so the precise semantics are subject to change, but it's likely to be "suitable as an equivalent to volatile in C" or something like that.