Remove codec::Encode and codec::Decode derives from generated APIs by default
#2008
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jsdw
changed the title
codec::Encode and codec::Decode from generated APIs by defaultcodec::Encode and codec::Decode derives from generated APIs by default
lexnv
reviewed
May 27, 2025
lexnv
reviewed
May 27, 2025
lexnv
reviewed
May 27, 2025
| @@ -206,7 +206,7 @@ fn generate_storage_entry_fns( | |||
| let key = &keys_slice[0]; | |||
| if key.hasher.ends_with_key() { | |||
| let arg = &key.arg_name; | |||
| let keys = quote!(#static_storage_key::new(#arg.borrow())); | |||
| let keys = quote!(#static_storage_key::new(#arg)); | |||
There was a problem hiding this comment.
We don't use references anymore because we need the self of the key to work with EncodeAsType and DecodeAsType?
There was a problem hiding this comment.
The basic reason was just because previously we would SCALE encode the key before doing anything with it, but now we want to avoid SCALE encoding and so we keep the key itself, requiring us to have ownership of the key.
It might be that we can allow the stored key to be a reference as well or something like that, because we only need it for long enough to encode it given actual metadata!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Most APIs in Subxt haven't used
codec::Encodeorcodec::Decodein a while; these traits encode and decode bytes from/to a chain based on the precise shape of our generated types and don't take into account any changes in the chain metadata.One of the issues we recently hit was #2006, whereby
EncodeandDecodederives in our generated APIs were not playing nicely with compact encoded generics.A solution is to migrate our generated APIs away from using
codec::Encodeorcodec::Decodeand relying only onEncodeAsTypeandDecodeAstype, which take the chain metadata into account and handle things like encoding and decoding compact encoded values transparently. This PR takes this path.As a nice side effect, the generated code size is reduced in line count by ~10%.
Users can still derive
EncodeandDecodethemselves on types that they want these traits on, or on everything, but all of the main Subxt interfaces no longer have any reliance on them, and so they do not need to be derviced by default.Closes #2006