Add a const spec_id and build markers from it

[leighmcculloch]

Warning

Spike. Part of a stack of PRs that must merge in this order:

1. Widen user-defined type name limit stellar-xdr#312
2. Add borrowed Ref variants of generated types rs-stellar-xdr#560
3. Add const XDR serialization on View types rs-stellar-xdr#562
4. Regenerate with widened UDT name limit rs-stellar-xdr#566
5. Encode contract spec XDR at const evaluation time #1965
6. this PR
7. Qualify user-defined type names #1970

This PR targets #1965's handcode-spec-refs-in-derives branch, so the diff here is only the spec id changes. Split out of #1970, which now targets this branch because it depends on this change.

What

Give every user-defined type that has a spec entry a spec_id() const fn, the first eight bytes of the SHA256 of that type's own spec entry XDR hashed at const evaluation time, and assemble the spec shaking v2 marker from that id instead of hashing the entry in the proc macro.

Why

A marker only matches if it hashes the same bytes the spec entry encodes to in the wasm, and the proc macro cannot always know those bytes, because it sees the tokens of the type it expands and nothing more. #1970 makes that concrete by naming a type with module_path!(), which no macro can resolve, so a macro-computed hash misses every entry and spec shaking strips the whole spec. Hashing where the entry is built keeps the two in step by construction. Naming the result spec_id() also gives a spec entry an identifier short enough to be referred to by something other than its full XDR.

Known limitations

Hashing at const evaluation needs a const SHA256, which the sha2 crate does not offer, so this adds sha2-const as a dependency of soroban-sdk.

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	sha2-const@​0.1.3

View full report