EnvBase is exported but shouldn't be

[leighmcculloch]

Follow on from:

• EnvBase is exposed in docs #1171

At the moment generated code is directly using the EnvBase and Guest fns, when it should be using SDK functionality. Generated code should make sense to developers and be handle writable. The optimizations that EnvBase offers should also be usable in the SDK.

Today what we have is optimizations used in the generated code that aren't usable outside of it with SDK types.

This issue should involve adding functions to SDK type to surface the EnvBase functionality. Then generated code can be updated to use those SDK functions.

[graydon]

Fwiw EnvBase is not just there for optimizations: it provides methods that support Rust-language abstractions (Panics and slices) that are higher level than the Env interface, because the Env interface contains some stuff that's based on wasm-semantics (VM traps and linear memory addresses) that do not exist when compiling in Env=Host local-testing mode (the mode without an interposed wasm VM). Like .. wasm linear memory addresses are 32 bit, whereas when running in Env=Host mode on a 64-bit machine, slice pointers are 64 bit. They literally can't pass through an interface phrased in terms of linear memory addresses. Likewise a VM trap that halts the guest isn't a thing when running in Env=Host mode; the effect is emulated with Rust panics but they are fundamentally different machinery.

Not that any of this is necessarily "stuff to show to users", but like .. EnvBase is there for a reason and fully erasing or removing it isn't likely to be possible if we keep Env=Host mode.

[leighmcculloch]

I don't think this is blocking anything in particular at this moment, so I think we can close it.