Argh, sorry. I should have read the code more carefully. You are right.
No, both of these would be questionable. Any time you do anything with inline assembly that has effects on Rust-visible state (such as the value of local variables, or the contents of memory that Rust knows about), if those same effects would be impossible to create using pure Rust, that is questionable.
Inline assembly cannot be used to extend Rust's ability to act on its own state. This is crucial to ensure correct compilation, since the compiler, when optimizing function X, will justify its correctness for an arbitrary Rust program calling that function -- not an arbitrary assembly program.
I don't see how that can work, since freeze by definition makes it non-UB to expose the contents of uninit memory -- and unsafe is for UB only.
I agree your use of freeze is fine from a security perspective. But I don't think we can use unsafe to ensure such a property, similar to how we do not unsafe to mark potential memory leaks. Rather, if we add freeze, we should probably carefully document that there is a general expectation that the values picked by freeze should not leak into the rest of the program.
Indeed. So when previously you talked about "two possible semantics that one could choose for fn freeze(&mut MaybeUninit<T>)", that was a misnomer -- the semantics of freeze in the Rust Abstract Machine is to turn uninit bytes into arbitrary init bytes. What you described were possible implementations of that semantics.