commit b8ce2c15227679e60c2e43af45f968f94b880564
author Devin Jeanpierre <jeanpierreda@google.com> Wed Jul 13 10:34:01 2022 -0700
committer Copybara-Service <copybara-worker@google.com> Wed Jul 13 10:34:35 2022 -0700
tree 64d78022036be319e4d041868b79815e3040ea3e
parent b9ddc4513c37df862800a3afe1e47c4f2c1973af

Return `!Unpin` objects by value.

To reduce complexity of this change, I avoided two obvious optimizations:

1. I chose to use the same scheme for both trivially relocatable and non-trivially-relocatable !Unpin values. I _could_ have used a different scheme for trivially relocatable ones, which avoided the extra thunk -- I opted to instead have that as a TODO, as it's a relatively simple extension that we would only do for performance.

2. This CL always generates a thunk for such functions. Indeed, my initial attempt at a CL involved adding a "pretend" parameter representing the output return slot, inside the C++ AST visitor, so that we could call the real underlying function directly. However, this turns out to be difficult to do right: aside from trivial concerns like "where do we get a lifetime from?", there's a more significant concern of, well, it's an ABI implementation detail that clang actually does not expose anywhere except during codegen, and so it's really tricky to get right. Instead, I opted for, uh, just creating a thunk every time. And the thunk can accept an extra out parameter in the API. This is *substantially* less code/complexity, at lower risk. (Kudos to Martin for pushing back and suggesting this!)

Worth making special mention that the return value of operator= is treated specially, as it is discarded (and must therefore be eagerly evaluated). That was a decision made earlier that we may want to revisit for higher fidelity, but for now I'm leaving it as is. (It's not yet implemented for !Unpin types, so that bit is slightly dead code.)

PiperOrigin-RevId: 460750558