rust - 在 T 和 UnsafeCell 之间转换是否安全且已定义行为？

Question

recent question正在寻找构建自我参照结构的能力。在讨论问题的可能答案时，一个可能的答案涉及使用 UnsafeCell 用于内部可变性，然后通过 transmute “丢弃”可变性.

这是这种想法在行动中的一个小例子。我对这个例子本身并不感兴趣，但它足够复杂，需要一个更大的锤子，比如 transmute而不是仅仅使用 UnsafeCell::new 和/或 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> ?

Answer 1

(我对 SO 还是个新手，不确定“好吧，也许”是否有资格作为答案，但你去吧。;)

免责声明:这类事情的规则(还)不是一成不变的。所以，目前还没有确定的答案。我将根据 (a) LLVM 执行/我们最终想要做的编译器转换类型，以及 (b) 我脑中将定义答案的模型类型做出一些猜测。

另外，我看到了两个部分:数据布局透视图和别名透视图。布局问题是NotReallyImmutable原则上，可以具有与 ReallyImmutable 完全不同的布局.我对数据布局不太了解，但对 UnsafeCell成为repr(transparent)这是这两种类型之间的唯一区别，我认为目的是要使其起作用。但是，您依赖于 repr(transparent)从某种意义上说，它是“结构化的”，它应该允许您替换较大类型的内容，我不确定是否已在任何地方明确写下。听起来像是一个关于扩展 repr(transparent) 的后续 RFC 的提议。适当保证？

就别名而言，问题是违反了 &T 周围的规则。 .我会这么说，只要你从来没有直播 &T通过 &UnsafeCell<T> 在任何地方书写时，你很好——但我认为我们还不能保证这一点。让我们更详细地看一下。

编译器视角

这里的相关优化是利用 &T 的优化。只读。因此，如果您重新排序最后两行( transmute 和赋值)，该代码可能是 UB，因为我们可能希望编译器能够“预取”共享引用后面的值并重新使用该值稍后(即在内联之后)。

但是在您的代码中，我们只会在 noalias 之后发出“只读”注释(LLVM 中的 transmute)。回来了，数据确实从那里开始是只读的。所以，这应该是好的。

内存模型

我的内存模型中“最激进的”本质上是 asserts that all values are always valid ，我认为即使是该模型也应该适用于您的代码。 &UnsafeCell是该模型中的一个特例，其中有效性刚刚停止，并且没有说明此引用背后的内容。当下transmute返回时，我们获取它指向的内存并将其全部设为只读，即使我们通过 Rc“递归地”执行此操作(我的模型没有，但只是因为我想不出一个好的方法来做到这一点)你会没事的，因为你在 transmute 之后不再变异了。 . (您可能已经注意到，这与编译器视角中的限制相同。毕竟，这些模型的重点是允许编译器优化。;)

(作为旁注，我真的希望 miri 现在处于更好的状态。似乎我必须尝试验证才能在那里再次工作，因为那样我可以告诉你只在 miri 中运行你的代码，它会告诉你如果我的模型的那个版本对你正在做的事情没问题:D)

我正在考虑目前仅检查“访问时”的其他模型，但还没有解决 UnsafeCell那个模型的故事呢。这个例子表明，模型可能必须首先包含内存“相变”的方式 UnsafeCell ，但后来有只读保证的正常共享。感谢您提出这一点，这将成为一些值得思考的好例子!

所以，我想我可以说(至少从我的角度来看)有允许这种代码的意图，并且这样做似乎并没有阻止任何优化。我们是否真的会设法找到一个每个人都同意并且仍然允许这样做的模型，我无法预测。

反方向:T -> UnsafeCell<T>
现在，这更有趣。问题是，正如我上面所说的，你不能有 &T通过写作时直播 UnsafeCell<T> .但这里的“活”是什么意思？这是一个很难的问题!在我的一些模型中，这可能与“该类型的引用存在于某处并且生命周期仍然有效”一样弱，即它可能与是否实际使用引用无关。 (这很有用，因为它让我们可以做更多的优化，比如将负载移出循环，即使我们不能证明循环曾经运行过——这会引入使用其他未使用的引用。)而且由于 &T是 Copy ，你甚至无法真正摆脱这样的引用。所以，如果你有 x: &T ，然后在 let y: &UnsafeCell<T> = transmute(x) 之后，老x仍然存在并且它的生命周期仍然活跃，所以写通过 y很可能是UB。

我认为您必须以某种方式限制 &T 的别名。允许，非常小心地确保没有人仍然持有这样的引用。我不会说“这是不可能的”，因为人们总是让我感到惊讶(尤其是在这个社区；)但是 TBH 我想不出一种方法来完成这项工作。我很好奇你是否有一个例子，尽管你认为这是合理的。