commit cc61dad19e74a1c2cf3cc14fc27aa769c312501b
author Devin Jeanpierre <jeanpierreda@google.com> Tue Jul 19 01:40:09 2022 -0700
committer Copybara-Service <copybara-worker@google.com> Tue Jul 19 01:40:48 2022 -0700
tree 30c698a9f47044e947cafb7fbce22b94a06a6463
parent c4fa436a2e3cda66440d67dd29e409e563d5c539

Mark classes as `final` in the tests and goldens.

These I think were meant to be `final`, and their output was incorrect: when we correctly support non-`final` classes, the interfaces here will change to accept `impl Ctor<Output=T>`, not `T` itself.

---

A quick reminder why (since I often forget the details myself): `Pin<&mut T>` has a [`set(T)` method](https://doc.rust-lang.org/std/pin/struct.Pin.html#method.set), and base classes aren't safe to Rust-assign to (including via `set()`). This is true both because Rust-assignment destroys the target (UB for a base class), but also because Rust-assignment overwrites `sizeof(T)` bytes, and derived classes can live inside of that span (e.g. via [EBO](https://en.cppreference.com/w/cpp/language/ebo), though it's more general than that).

Because set exists, but must never be called, we forbid access to the raw `T` type. This ends up being the same as how we treat trivially relocatable functions. (However, note that this decision is reversible if we choose to stop using `Pin`.)  And so, even though it would obviously be safe to use a `T` by value in by-value parameters or return types, we forbid it anyway, because it would allow for unsafe behavior when you have references.

This explanation will become more salient with the followup change, which actually implements pass-by-value for `!Unpin` types (including non-`final` types). Woo!

PiperOrigin-RevId: 461824564