Macro for setting the contract's state version in the compiled binary

[kulikthebird]

The purpose of the new macro is to provide the contract's state version directly in the contract's binary. Once provided, the VM could implement the conditional migrate call procedure to reduce redundant migrate entry point calling.

Procedural attribute-like macro

A proc-macro that can be called on the migrate entry point only.

#[entry_point]
#[set_contract_state_version(3)]
pub fn migrate(deps: DepsMut, env: Env, info: MigrateInfo, _msg: MigrateContract) -> StdResult<Response> {
    // [...]
}

[aumetra]

I personally think a good solution would be something like cw_contract_state_version as the name of a custom section, and the value is just the value of the version

(maybe as an integer, maybe we could also make the affordance and enforce it to be UTF-8 bytes, therefore allowing for more complex versions, such as SemVer-encoded versions)

[aumetra]

Another thing to keep in mind: If we want to have tests for this (and we most definitely do), creating a WASM binary from WAT with a custom section requires the payload to be a string, simply because of how the WAT is defined.
The binary format has no such limitations.

For example, this works, but this does not, so if we want to write tests in WAT, then we pretty much have to choose strings.

Otherwise we can try to assemble these things ourselves by using wasm-encoder

[webmaster128]

I would like the value to be readable using wasm-objdump (see notes here for the working title cw2++). This would then also require the value to be a string and not some big endian number.

[aumetra]

Okay, now that we pretty much settled on using strings, should we enforce the usage of something like SemVer? Because that way it's nicely structured from a user point of view, and we can do easy comparisons whether the contract is newer, older, or the same version.

[webmaster128]

In the context of state versioning, I don't see a value in using anything non-integer. It just adds complexity but what you need is incremental steps for migrations.

[aumetra]

Fair, fair. So stringify integer inside the macro -> upon loading, check if the versioning from the last revision is old+1 (if it isn't, error out, I guess?) -> run migrations?

[webmaster128]

Almost:

1. If state_version_new_code != state_version_old_code, wasmd calls the migrate entry point of the contract. Otherwise the code is swapped but the migrate implementation is bypassed
2. In fn migrate( the contract developer gets the old version and can do anything smart with that information. You can imagine an implementation in version 5 that is able to migrate from 2, 3 and 4 but not 1.

[aumetra]

the contract developer gets the old version and can do anything smart with that information

Fair, I was thinking in terms of lock-step migration, but that makes sense.

[webmaster128]

After #2124 what we also need is a function in the VM that can read the version from a contract by checksum. Wasmd could do that directly but then we'd have to copy the whole Wasm blob around. The VM can implement that more efficiently and in Rust.

[aumetra]

The VM can implement that more efficiently and in Rust.

Yeah, it's actually also not that hard to implement. wasmparser and then just step through the components.