在 T 和 UnsafeCell<T> 之间转换是否安全且已定义的行为？
Is it safe and defined behavior to transmute between a T and an UnsafeCell<T>?
一个 was looking for the ability to construct self-referential structures. In discussing possible answers for the question, one potential answer involved using an UnsafeCell for interior mutability and then "discarding" the mutability through a transmute.
下面是一个将这种想法付诸实践的小例子。我对这个例子本身并不很感兴趣，但它已经足够复杂了，需要像 transmute 这样的更大的锤子，而不是仅仅使用 UnsafeCell::new and/or UnsafeCell::into_inner:
use std::{
cell::UnsafeCell, mem, rc::{Rc, Weak},
};
// This is our real type.
struct ReallyImmutable {
value: i32,
myself: Weak<ReallyImmutable>,
}
fn initialize() -> Rc<ReallyImmutable> {
// This mirrors ReallyImmutable but we use `UnsafeCell`
// to perform some initial interior mutation.
struct NotReallyImmutable {
value: i32,
myself: Weak<UnsafeCell<NotReallyImmutable>>,
}
let initial = NotReallyImmutable {
value: 42,
myself: Weak::new(),
};
// Without interior mutability, we couldn't update the `myself` field
// after we've created the `Rc`.
let second = Rc::new(UnsafeCell::new(initial));
// Tie the recursive knot
let new_myself = Rc::downgrade(&second);
unsafe {
// Should be safe as there can be no other accesses to this field
(&mut *second.get()).myself = new_myself;
// No one outside of this function needs the interior mutability
// TODO: Is this call safe?
mem::transmute(second)
}
}
fn main() {
let v = initialize();
println!("{} -> {:?}", v.value, v.myself.upgrade().map(|v| v.value))
}
此代码似乎打印出我所期望的内容，但这并不意味着它是安全的或使用定义的语义。
从 UnsafeCell<T> 转换为 T 内存安全吗？它会调用未定义的行为吗？向相反方向转变，从 T 到 UnsafeCell<T> 怎么样？
（我对 SO 还是陌生的，不确定 "well, maybe" 是否符合答案的条件，但是给你。;）
免责声明：这类事情的规则（还）不是一成不变的。所以，目前还没有确定的答案。我将根据 (a) LLVM does/we 最终想要做什么样的编译器转换，以及 (b) 我脑海中有什么样的模型来定义这个问题的答案来做一些猜测.
此外，我看到了两个部分：数据布局透视图和别名透视图。布局问题是 NotReallyImmutable 原则上可能与 ReallyImmutable 具有完全不同的布局。我不太了解数据布局，但是随着 UnsafeCell 变成 repr(transparent) 并且这是两种类型之间的唯一区别，我认为 intent 是为了这个工作。但是，您依赖 repr(transparent) 是 "structural"，因为它应该允许您替换更大类型的东西，我不确定是否已在任何地方明确写下。听起来像是关于适当扩展 repr(transparent) 保证的后续 RFC 的提案？
就别名而言，问题是违反了 &T 周围的规则。我想说的是，只要您在通过 &UnsafeCell<T> 写入时从未在任何地方有实时 &T，您就很好 — 但我认为我们还不能保证这一点。让我们看得更详细一些。
编译器视角
这里的相关优化是利用 &T 是只读的。因此，如果您重新排序最后两行（transmute 和赋值），该代码可能是 UB，因为我们可能希望编译器能够 "pre-fetch" 共享引用背后的值并重新使用该值稍后（即在内联后）。
但是在您的代码中，我们只会在 transmute 返回后发出 "read-only" 注释（LLVM 中的 noalias），并且从那里开始数据确实是只读的。所以，这应该不错。
内存模型
我的内存模型 "most aggressive" 本质上是 asserts that all values are always valid，我认为即使是那个模型也应该适合您的代码。 &UnsafeCell 是该模型中的一个特例，其中有效性刚刚停止，并且没有说明此引用背后的内容。在 transmute returns 的那一刻，我们获取它指向的内存并将其全部设置为只读，即使我们通过 Rc （我的model 没有，但只是因为我想不出一个好的方法来让它这样做）你会没事的，因为你在 transmute 之后不再变异了。 （您可能已经注意到，这与编译器角度的限制相同。毕竟，这些模型的重点是允许编译器优化。;）
（作为旁注，我真的希望 miri 现在的状态更好。看来我必须尝试验证才能在那里再次工作，因为那样我就可以告诉你 运行你在 miri 中的代码，它会告诉你我的模型版本是否适合你正在做的事情 :D )
我正在考虑目前仅检查内容 "on access" 但尚未为该模型制定 UnsafeCell 故事的其他模型。这个例子表明，该模型可能必须包含 "phase transition" 内存的方式，首先是 UnsafeCell，但随后通过只读保证进行正常共享。感谢您提出这个问题，这将有助于思考一些很好的例子！
所以，我想我可以说（至少从我这边来说）有 intent 允许这种代码，这样做似乎并不能阻止任何优化。我们是否真的能够找到一个每个人都能同意并且仍然允许这样做的模型，我无法预测。
反方向：T -> UnsafeCell<T>
现在，这更有趣了。问题是，正如我上面所说，通过 UnsafeCell<T> 写入时，您一定不能有 &T 活。但是 "live" 在这里是什么意思？这是一个很难的问题！在我的一些模型中，这可能和 "a reference of that type exists somewhere and the lifetime is still active" 一样弱，也就是说，它可能与引用是否实际 使用 无关。 （这很有用，因为它可以让我们做更多的优化，比如即使我们不能证明循环曾经 运行s 也将负载从循环中移出——这将引入对其他未使用的引用的使用。）并且由于&T 是 Copy，你甚至无法真正摆脱这样的引用。所以，如果你有 x: &T，那么在 let y: &UnsafeCell<T> = transmute(x) 之后，旧的 x 仍然存在并且它的生命周期仍然有效，所以通过 y 写入很可能是 UB。
我认为你必须以某种方式限制 &T 允许的别名，非常小心地确保没有人仍然持有这样的参考。我不会说 "this is impossible"，因为人们总是让我感到惊讶（尤其是在这个社区中；）但是说实话，我想不出一种方法来完成这项工作。我很好奇你是否有一个你认为这是合理的例子。
一个UnsafeCell for interior mutability and then "discarding" the mutability through a transmute.
下面是一个将这种想法付诸实践的小例子。我对这个例子本身并不很感兴趣，但它已经足够复杂了，需要像 transmute 这样的更大的锤子，而不是仅仅使用 UnsafeCell::new and/or UnsafeCell::into_inner:
use std::{
cell::UnsafeCell, mem, rc::{Rc, Weak},
};
// This is our real type.
struct ReallyImmutable {
value: i32,
myself: Weak<ReallyImmutable>,
}
fn initialize() -> Rc<ReallyImmutable> {
// This mirrors ReallyImmutable but we use `UnsafeCell`
// to perform some initial interior mutation.
struct NotReallyImmutable {
value: i32,
myself: Weak<UnsafeCell<NotReallyImmutable>>,
}
let initial = NotReallyImmutable {
value: 42,
myself: Weak::new(),
};
// Without interior mutability, we couldn't update the `myself` field
// after we've created the `Rc`.
let second = Rc::new(UnsafeCell::new(initial));
// Tie the recursive knot
let new_myself = Rc::downgrade(&second);
unsafe {
// Should be safe as there can be no other accesses to this field
(&mut *second.get()).myself = new_myself;
// No one outside of this function needs the interior mutability
// TODO: Is this call safe?
mem::transmute(second)
}
}
fn main() {
let v = initialize();
println!("{} -> {:?}", v.value, v.myself.upgrade().map(|v| v.value))
}
此代码似乎打印出我所期望的内容，但这并不意味着它是安全的或使用定义的语义。
从 UnsafeCell<T> 转换为 T 内存安全吗？它会调用未定义的行为吗？向相反方向转变，从 T 到 UnsafeCell<T> 怎么样？
（我对 SO 还是陌生的，不确定 "well, maybe" 是否符合答案的条件，但是给你。;）
免责声明：这类事情的规则（还）不是一成不变的。所以，目前还没有确定的答案。我将根据 (a) LLVM does/we 最终想要做什么样的编译器转换，以及 (b) 我脑海中有什么样的模型来定义这个问题的答案来做一些猜测.
此外，我看到了两个部分：数据布局透视图和别名透视图。布局问题是 NotReallyImmutable 原则上可能与 ReallyImmutable 具有完全不同的布局。我不太了解数据布局，但是随着 UnsafeCell 变成 repr(transparent) 并且这是两种类型之间的唯一区别，我认为 intent 是为了这个工作。但是，您依赖 repr(transparent) 是 "structural"，因为它应该允许您替换更大类型的东西，我不确定是否已在任何地方明确写下。听起来像是关于适当扩展 repr(transparent) 保证的后续 RFC 的提案？
就别名而言，问题是违反了 &T 周围的规则。我想说的是，只要您在通过 &UnsafeCell<T> 写入时从未在任何地方有实时 &T，您就很好 — 但我认为我们还不能保证这一点。让我们看得更详细一些。
编译器视角
这里的相关优化是利用 &T 是只读的。因此，如果您重新排序最后两行（transmute 和赋值），该代码可能是 UB，因为我们可能希望编译器能够 "pre-fetch" 共享引用背后的值并重新使用该值稍后（即在内联后）。
但是在您的代码中，我们只会在 transmute 返回后发出 "read-only" 注释（LLVM 中的 noalias），并且从那里开始数据确实是只读的。所以，这应该不错。
内存模型
我的内存模型 "most aggressive" 本质上是 asserts that all values are always valid，我认为即使是那个模型也应该适合您的代码。 &UnsafeCell 是该模型中的一个特例，其中有效性刚刚停止，并且没有说明此引用背后的内容。在 transmute returns 的那一刻，我们获取它指向的内存并将其全部设置为只读，即使我们通过 Rc （我的model 没有，但只是因为我想不出一个好的方法来让它这样做）你会没事的，因为你在 transmute 之后不再变异了。 （您可能已经注意到，这与编译器角度的限制相同。毕竟，这些模型的重点是允许编译器优化。;）
（作为旁注，我真的希望 miri 现在的状态更好。看来我必须尝试验证才能在那里再次工作，因为那样我就可以告诉你 运行你在 miri 中的代码，它会告诉你我的模型版本是否适合你正在做的事情 :D )
我正在考虑目前仅检查内容 "on access" 但尚未为该模型制定 UnsafeCell 故事的其他模型。这个例子表明，该模型可能必须包含 "phase transition" 内存的方式，首先是 UnsafeCell，但随后通过只读保证进行正常共享。感谢您提出这个问题，这将有助于思考一些很好的例子！
所以，我想我可以说（至少从我这边来说）有 intent 允许这种代码，这样做似乎并不能阻止任何优化。我们是否真的能够找到一个每个人都能同意并且仍然允许这样做的模型，我无法预测。
反方向：T -> UnsafeCell<T>
现在，这更有趣了。问题是，正如我上面所说，通过 UnsafeCell<T> 写入时，您一定不能有 &T 活。但是 "live" 在这里是什么意思？这是一个很难的问题！在我的一些模型中，这可能和 "a reference of that type exists somewhere and the lifetime is still active" 一样弱，也就是说，它可能与引用是否实际 使用 无关。 （这很有用，因为它可以让我们做更多的优化，比如即使我们不能证明循环曾经 运行s 也将负载从循环中移出——这将引入对其他未使用的引用的使用。）并且由于&T 是 Copy，你甚至无法真正摆脱这样的引用。所以，如果你有 x: &T，那么在 let y: &UnsafeCell<T> = transmute(x) 之后，旧的 x 仍然存在并且它的生命周期仍然有效，所以通过 y 写入很可能是 UB。
我认为你必须以某种方式限制 &T 允许的别名，非常小心地确保没有人仍然持有这样的参考。我不会说 "this is impossible"，因为人们总是让我感到惊讶（尤其是在这个社区中；）但是说实话，我想不出一种方法来完成这项工作。我很好奇你是否有一个你认为这是合理的例子。