Skip to content

Conversation

@rustopian
Copy link

@rustopian rustopian commented Nov 14, 2025

Most of the diff is generated code (clients and lockfiles) - CI demands it

Problem

Client generation uses a lot of fragile manual scripting.

Solution

Update to using Codama macros, including the new Codama support for doc fields and tuples as instruction arguments.

@rustopian rustopian changed the title update to use codama macros [WIP] update to use codama macros Nov 14, 2025
@rustopian rustopian requested a review from grod220 November 14, 2025 22:17
@rustopian rustopian changed the title [WIP] update to use codama macros IDL: [WIP] update to use codama macros Nov 14, 2025
@rustopian rustopian marked this pull request as ready for review November 24, 2025 11:24
@rustopian rustopian changed the title IDL: [WIP] update to use codama macros IDL: update to use codama macros Nov 24, 2025
Copy link
Member

@grod220 grod220 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very cool!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Relevant feedback from another PR: solana-program/record#130 (comment). The feedback on build.rs, makefile+ci/cd support, and feature flagging is worth including here too.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice tip, added all of this

Initialize(Authorized, Lockup),
#[codama(account(name = "stake", writable, docs = "Uninitialized stake account"))]
#[codama(account(name = "rent_sysvar", docs = "Rent sysvar"))]
Initialize { arg0: Authorized, arg1: Lockup },
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need codama support for the tuple variant as this is a breaking change

Copy link
Author

@rustopian rustopian Dec 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PRed upstream at codama-idl/codama-rs#73, and now the tuples are restored in this PR

},
{
// Use omitted optional account strategy for all instructions.
// + fix discriminator u8 -> u32.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the story with this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we have to do this if the macro is

 #[codama(enum_discriminator(size = number(u32)))]

Copy link
Author

@rustopian rustopian Dec 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Originally fixed at this level in #54

This is still the behavior of things. Despite the macro specifying u32, the IDL ends up with u8 and the clients do as well.

If you remove this tiny fix, all clients will have u8s and U8Decoder etc.

Comment on lines 186 to 190
// Resolve default values.
if (!accounts.clockSysvar.value) {
accounts.clockSysvar.value =
'SysvarC1ock11111111111111111111111111111111' as Address<'SysvarC1ock11111111111111111111111111111111'>;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can specify default values in the macro like:

#[codama(account(
    name = "clock_sysvar",
    docs = "Clock sysvar",
    default_value = "SysvarC1ock11111111111111111111111111111111"
))]

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've done a visitor here instead since Codama doesn't (yet) handle Pubkey types correctly without custom handling. It should create a publicKeyValueNode but doesn't.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@grod220 I found out that codama does these differently. This works!

default_value = sysvar("clock")

Cf https://github.com/codama-idl/codama-rs/blob/main/codama-attributes/src/codama_directives/value_nodes/sysvar.rs#L5

}

Instruction::new_with_bincode(ID, &StakeInstruction::Withdraw(lamports), account_metas)
Instruction::new_with_bincode(ID, &StakeInstruction::Withdraw { lamports }, account_metas)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Think we should keep these fns for forward compatibility (for now) and swap out the innards where the account metas / inputs are manually being written---for the new builders. Given these are used in tests (I think) it will also validate the builders work against test code.

Copy link
Author

@rustopian rustopian Dec 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this! Will work on this a subsequent PR, if that's okay with you.

"$schema": "https://codama.gg/schemas/codama.json",
"idls": [
{
"path": "interface/idl.json",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

separately: what's the deal with program/idl.json? Should that be deleted?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup, old file. Removed

Comment on lines 271 to 274
pub enum StakeAuthorize {
Staker,
Withdrawer,
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need a codama enum attr?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added 🙏

@rustopian rustopian marked this pull request as draft December 4, 2025 13:45
@rustopian rustopian marked this pull request as ready for review December 4, 2025 17:00
@rustopian rustopian requested a review from grod220 December 4, 2025 17:00
@rustopian rustopian marked this pull request as draft December 4, 2025 17:02
@rustopian rustopian force-pushed the codama branch 5 times, most recently from a205eed to d2ac5e8 Compare December 4, 2025 18:11
@rustopian rustopian marked this pull request as ready for review December 4, 2025 18:32
@rustopian rustopian marked this pull request as draft December 9, 2025 08:20
@rustopian rustopian marked this pull request as ready for review December 9, 2025 09:50
Copy link
Member

@grod220 grod220 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Amazing work, think we are close!

Comment on lines +21 to +22
codama = { version = "0.6.5", git = "https://github.com/rustopian/codama-rs", branch = "custom-tuple-arg-names", optional = true }
codama-macros = { version = "0.6.5", git = "https://github.com/rustopian/codama-rs", branch = "custom-tuple-arg-names", optional = true }
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any chance a release is coming soon? :)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup Loris since published 6.6, will update!

"@codama/nodes-from-anchor": "^1.3.6",
"@codama/renderers-js": "^1.4",
"@codama/renderers-rust": "~1.0",
"@codama/renderers-rust": "1.2.9",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably can go with ^1.2.9 versus being pinned

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We probably need these right?

Comment on lines +52 to +62
// Add Epoch type alias
c.definedTypeNode({
name: 'epoch',
type: c.numberTypeNode('u64'),
}),
// Add UnixTimestamp type alias
c.definedTypeNode({
name: 'unixTimestamp',
type: c.numberTypeNode('i64'),
}),
...node.definedTypes,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any motivation for these?

Copy link
Author

@rustopian rustopian Dec 9, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The clarity of named types (as in the program itself)

Comment on lines +38 to +40
// Unwrap defined type links used only as instruction args, then flatten them
codama.update(c.unwrapInstructionArgsDefinedTypesVisitor());
codama.update(c.flattenInstructionDataArgumentsVisitor());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, having a hard time understanding this one. Can you give more context?

Comment on lines +125 to +129
arguments: node.arguments.map((arg) =>
arg.name === 'discriminator'
? { ...arg, type: c.numberTypeNode('u32') }
: arg
),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this due to the codama dep bump where discriminators are added?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants