expand on the Send/Sync situation for consts #33
Conversation
| per-thread recomputation which would lead to different addresses. As a | ||
| consequence, non-`Send` `const` without references are fine, but once references | ||
| and thus address identity comes into play, we have a problem. | ||
|
|
||
| *Dynamic check.* It is unclear how the Miri engine could dynamically check this. |
There was a problem hiding this comment.
I started implementing this before we had validation because I thought we could scrap some of const qualif for a value analysis. What I was basically doing is what validation is doing, but looked for explicit unsafe impl Send or unsafe impl Sync on the type of the value currently being validated. Aggregates that got their trait impls due to the auto trait nature and not explicit impls were simply walked. This permitted Option<*const u8>::None but forbade Option<*const u8>::Some(&1)
There was a problem hiding this comment.
I doubt we can actually get away with forbidding Option<*const u8>::Some(&1) though...
What I was basically doing is what validation is doing, but looked for explicit unsafe impl Send or unsafe impl Sync on the type of the value currently being validated.
Yeah, I had thoughts along those lines, too. Unfortunately though, negative impls aren't stable yet, so it seems plausible people might do things like add a PhantomData<*const ()> field as a "no-Sync" marker... :/
I think conceptually it makes more sense to start from "
constought to beSend" and then argue that thus, the data behind shared references should beSync.