Result makes sense where I have something meaningful to say to the user like
"X is not implemented yet". And also for public functions that may interface
with other parts of the project like Backend.
But for private functions internal to gen_wasm, it's just unhelpful to get a stack trace
to where the Result is unwrapped! I want a stack trace to the root cause.
I always end up temporarily rewriting Err("oops") to panic!("oops") and then waiting
for it to recompile.
This feels like a more balanced approach, using each technique where it makes sense.
We don't have much (any) code that cares about the difference between
heap pointers and other primitives, but we have a _lot_ of code that cares
if it's stack memory. So let's encode it that way.
SymbolStorage is function-specific, whereas WasmLayout is function-independent.
SymbolStorage used to be a single-variant enum with a LocalId and a WasmLayout,
but now we need more variants, so we can handle stack memory allocation..
- For values in stack memory, the storage needs to include an offset within the
stack frame, but we don't need that for primitive values.
- For function parameters, the allocated stack memory is in the caller's frame
rather than the current frame, so we don't want size or offset.
We could have kept a WasmLayout inside of SymbolStorage but that would have made
possible a lot of invalid combinations. It seemed better to copy the fields we need.
