WebAssembly
Refactor BinaryenSetMemory API
In a follow-up we'll want to refactor this API so that segments are not so closely tied to memories. Looking at the behavior below, it looks like this function blows away any existing segments and memories, so this API isn't really safe to use in a multi-memory context at all. Given that, I think it would make sense to assume this will only be used with non-multi-memory code and have it unconditionally use name "0" rather than taking an explicit name.
Originally posted by @tlively in https://github.com/WebAssembly/binaryen/pull/4811#discussion_r933608309
It might be clearer to make this more explicit by doing something like memory->max = maximum == -1 ? Address::kUnlimitedSize : maximum; (although I see this was preexisting code).
Originally posted by @tlively in https://github.com/WebAssembly/binaryen/pull/4811#discussion_r933612470
It's more efficient to use the existing unique ptr rather than releasing it just for a new one to be created inside addExport.
- ((Module*)module)->addExport(memoryExport.release());
+ ((Module*)module)->addExport(std::move(memoryExport));
Originally posted by @tlively in https://github.com/WebAssembly/binaryen/pull/4811#discussion_r933616239
We should also do something with any existing memory exports. Probably deleting them makes the most sense, but that would be a functional change, since previously they would have implicitly switched to exporting the new memory.
Originally posted by @tlively in https://github.com/WebAssembly/binaryen/pull/4811#discussion_r933620271