feat(CLI): Typed rendering for call output by marijamijailovic · Pull Request #2179 · 0xMiden/rust-sdk

marijamijailovic · 2026-05-13T08:42:23Z

This PR extends the call command: it now looks for type info in the package's debug sections, and if it's there it prints a typed signature and decodes the result (for now account-id, bool, word, structs) instead of showing raw felts. If there's no type info it just prints the raw stack like before, so nothing changes for existing packages.

It reads two sections from the package - DEBUG_FUNCTIONS (the procedure name, its params and signature) and DEBUG_TYPES (the type definitions). With those, the args you pass on the CLI get encoded according to the parameter types (e.g. an account-id hex token expands to two felts, a word to four), and the returned felts get decoded back into the same types for printing.

Example, you'll get something like:

Signature: take-account-id(id: account-id) -> account-id
Result: account-id(0xa591009a3022e800788f9ed177dcdb)

Closes #2098

marijamijailovic · 2026-05-14T07:20:24Z

Hi @igamigo! Quick question about the changelog for this PR: there is already an entry saying “Added miden-cli call command for invoking account procedures directly from the CLI”. Should we reuse that existing entry for this PR as well, or to add a new changelog entry that explicitly mentions typed rendering for the call output?

igamigo · 2026-05-15T14:43:31Z

Hi @igamigo! Quick question about the changelog for this PR: there is already an entry saying “Added miden-cli call command for invoking account procedures directly from the CLI”. Should we reuse that existing entry for this PR as well, or to add a new changelog entry that explicitly mentions typed rendering for the call output?

I think we can reuse it and add this PR link to the same entry since it's very related, but not a strong opinion so if you prefer otherwise that's fine too.

igamigo · 2026-05-15T14:45:35Z

Can you expand the PR description explaining the design a bit and how it relates to the issue? And/or maybe add some examples of how this renders. I know there is some context there already but the actual implementation and the scope has not been fully discussed AFAICT

marijamijailovic · 2026-05-25T12:10:05Z

Hi @igamigo thanks for your comment! I updated the PR description.

There's one thing I just realized, and because of it I'm turning this into a draft: I accidentally tested it against a compiler branch that isn't merged into next yet, this branch is the one that stores the high-level types inside the debug sections. My bad, I didn't check that my cargo miden build was pointing at my local compiler on that branch instead of the official one from crates. So on packages built with the official compiler the debug sections are there, but it does not saves the functions signature with high level type, and the typed path won't trigger - it'll just fall back to raw.

Keinberger

Approve direction, but let's hold non-draft on the items below. Thanks @marijamijailovic!

Phase 1 from #2098 is covered.

Before flipping to non-draft though:

Test coverage. See inline on package_types/mod.rs — bool, u32, u64 are priority types from #2098 but have no unit test.
Compiler dependency. See inline on tests/cli.rs — the typed path only triggers because the test stubs the debug sections in by hand.
CHANGELOG. The check is still red and I can't drop an inline since CHANGELOG.md isn't in the diff. Per your thread with @igamigo, extending the existing #1943 entry sounds right, something like:

Added miden-cli call command for invoking account procedures directly from the CLI (#1943), with typed argument encoding and typed result rendering when the package carries debug type info (#2179).

Follow-ups to track separately, not here:

Phase 2 SchemaType rendering.
Module naming: package_types reads ambiguous next to the manifest's own FunctionType. Happy to be overruled.

Keinberger · 2026-05-27T14:26:52Z

+/// `call` command exercises its typed encode/decode path. Only this proc is annotated; `add`
+/// and `set_value` resolve to `None` in `TypedProcInfo` and stay on the raw path.
+fn build_take_account_id_debug_sections() -> (
+    miden_mast_package::debug_info::DebugFunctionsSection,


This helper is load-bearing for the typed test, and it exists because the official compiler does not emit DebugTypeInfo::Function entries yet (per your draft-state note above). That means the only end-to-end coverage of the typed path runs against hand-built debug sections.

Could you link the corresponding compiler PR or open a tracking issue so we have an explicit gate for "pioneers running cargo miden build against the published toolchain will see typed output"? I want to be sure we don't ship this and then quietly have everyone fall back to raw rendering until the compiler catches up.

marijamijailovic · 2026-06-01T05:28:00Z

I’ve pushed a follow-up that addresses the review comments on the typed ‎call data:

Added unit tests for ‎bool, ‎u32, and ‎u64, following the same pattern as ‎felt_roundtrip.
Renamed the module from ‎package_types to ‎package_debug_info (and ‎PackageTypesError to ‎PackageDebugInfoError).
Centralized type detection by moving the WIT names into ‎ACCOUNT_ID_TYPE / ‎WORD_TYPE constants with a short comment about the naming assumption, so there is a single place to update once the upstream compiler settles on names.
Updated the CHANGELOG by extending the existing ‎miden-cli call.
Documented in ‎tests/cli.rs that the published compiler does not yet emit typed ‎DebugTypeInfo::Function entries (those are added in compiler#1151, so packages built with the current toolchain still fall back to the raw path.
Switched digest resolution to go through the manifest (export name → digest) instead of ‎package.mast, since ‎mast is marked as unstable and will move from ‎Library to ‎MastForest.
Fixed anonymous-struct handling to use the ‎<anon> sentinel, so they render by field shape (e.g. ‎{x: felt, y: felt}), consistent with what the compiler currently emits and what is described in this comment.
Rust contract functions are usually written in ‎snake_case, but the Miden toolchain exports them as kebab-case (‎take_account_id → ‎take-account-id). To make this friendlier for users, ‎call now treats ‎_ and ‎- as equivalent when resolving procedure names, so both forms work. This also fixed integration tests whose MASM fixture uses bare snake names by normalizing both sides.
‎make clippy currently fails on ‎fs_keystore.rs:232 (‎get_signature) with ‎clippy::unused_async, which seems unrelated to the ‎call changes. I’m happy to fix that in this PR as well if you’d like CI to be green here.

cc @Keinberger @igamigo

marijamijailovic · 2026-06-04T08:17:43Z

cc @BrianSeong99 I am tagging you here so you are aware of this one

marijamijailovic · 2026-06-09T06:35:28Z

Hi @igamigo! Would it make sense to start the review while keeping this PR in draft until the compiler changes land, and then make this one “ready” once the compiler is ready as well?

igamigo

Overall I'm not entirely sure the new package_debug_info should be part of miden_client. It seems like it encompasses a bunch of package/compiler-related helpers and is not really used in the miden-client crate, only the CLI. In this sense, I wonder if it should be placed either in the CLI directly or as a separate compiler crate, as it's very much independent of the codebase here.

igamigo · 2026-06-11T19:22:50Z

+pub use self::encode::parse_felt_token;
+use self::encode::{arg_token_count, encode_tokens};
+pub use self::errors::PackageDebugInfoError;


nit: Let's move the pub use to be below the mod definitions (ie, below line 4 and 5). Let's also move all the imports to be above the mod definitions

igamigo · 2026-06-11T19:29:39Z

+    /// Encodes `tokens` as a flat felt vector matching the procedure's parameter types. `word`
+    /// and `account-id` each parse from a single hex token; other structs expect one token per
+    /// leaf field.
+    pub fn encode_args(&self, tokens: &[String]) -> Result<Vec<Felt>, PackageDebugInfoError> {


Do we need this function here? It seems like this is an application responsibility. For example, perhaps a CLI would be interested in taking strings and parsing them, but I don't think we need to make it a concern of TypedProcInfo. Perhaps it can take a list of felts and validate them against the proc info

marijamijailovic · 2026-06-12T14:30:32Z

Overall I'm not entirely sure the new package_debug_info should be part of miden_client. It seems like it encompasses a bunch of package/compiler-related helpers and is not really used in the miden-client crate, only the CLI. In this sense, I wonder if it should be placed either in the CLI directly or as a separate compiler crate, as it's very much independent of the codebase here.

Thanks, that’s a good point. I agree this probably live inmiden_client long‑term.

I'm thinking about moving the whole typed encoder/decoder into miden-vm/mast-package, under debug_info::typed. The main reason is that the the typed encoder/decoder into ‎mast-package, under ‎debug_info::typed. The main reason is that the encoder/decoder only needs the debug type table (‎DebugTypesSection / ‎DebugTypeInfo), and those types already live in ‎mast-package/src/debug_info/types.rs, so it feels more natural for the typed view to sit next to the data it consumes.

This way the split would be: the compiler writes the debug sections, ‎mast-package owns the debug types and the typed view over them, and client just consume it.

Let me know what do you think? And we can tag in people from the miden-vm / compiler side who can share their opinion.

igamigo · 2026-06-12T20:12:02Z

Hey @marijamijailovic / @Keinberger, just a heads up, if we want this on the 0.15.x we'll need to rebase this to main.

marijamijailovic · 2026-06-18T07:04:01Z

This PR is blocked for now.

miden-client exec and call do not work with the latest compiler on the next branch. We must wait for the fix first.
See: 0xMiden/compiler#1192

After the fix is introduce, I will:

Run full testing locally.
Mark this PR as ready for review.

So this PR stays in draft until then.

marijamijailovic · 2026-06-20T13:52:57Z

Hey @igamigo, rebased on main, miden-vm PR is open — 0xMiden/miden-vm#3276

marijamijailovic · 2026-06-20T13:54:34Z

This PR is blocked for now.

miden-client exec and call do not work with the latest compiler on the next branch. We must wait for the fix first.
See: 0xMiden/compiler#1192

After the fix is introduce, I will:

Run full testing locally.

Mark this PR as ready for review.

So this PR stays in draft until then.

The above issue is resolved.

igamigo · 2026-06-22T14:30:34Z

With the issue resolved are we now ready to move this PR out of draft and have it reviewed? Or were we waiting on the VM patch release?

marijamijailovic · 2026-06-23T09:42:10Z

With the issue resolved are we now ready to move this PR out of draft and have it reviewed? Or were we waiting on the VM patch release?

Thanks for bumping this up! Now that the ‎miden-vm PR is open, my slight preference would be to land the ‎miden-vm patch first so that we can point ‎Cargo.toml at a clean released dependency, and only then move this PR out of draft and mark it ready for review. If you’d prefer to start the review here in parallel with the VM patch, I’m happy to resolve all comments in parallel.

igamigo · 2026-07-22T20:05:13Z

Hi @marijamijailovic, would we be ready to move this PR out of draft or is there anything missing?

marijamijailovic · 2026-07-23T14:17:49Z

Hi @marijamijailovic, would we be ready to move this PR out of draft or is there anything missing?

Hi, not yet, as per comment, I'm now waiting for @bitwalker PR to land first, and then to update how miden call use debug info.

Drop the local package_debug_info module and consume the typed encoder/decoder from miden-mast-package's debug_info::typed instead.

bitwalker · 2026-07-28T13:32:56Z

@marijamijailovic 0.25.8 has landed, and the new debugger has shipped, so I think all the necessary pieces are in place for you now

igamigo

LGTM! Holding off on approving until we have upstream dependencies merged but leaving some mostly minor comments for now.

Also, can you update the PR description? It seems to have gotten stale.

igamigo · 2026-08-05T15:04:30Z

+    #[error("client has not been synced yet")]
+    #[diagnostic(
+        code(cli::not_synced),
+        help("Run `{} sync` first.", client_binary_name().display())
+    )]
+    NotSynced,


igamigo · 2026-08-05T15:06:51Z

 miden-client-sqlite-store = { workspace = true }
 miden-debug               = { optional = true, workspace = true }
+miden-mast-package        = { workspace = true }
+miden-protocol            = { workspace = true }


We should not need this import. AFAIK all types you are using are already being re-exported from miden-client

igamigo · 2026-08-05T15:09:56Z

+
+    if found_without_signature {
+        return Err(missing_signature(procedure_name));
    }


Previously it seems that such procedures would be callable with u64 args and a stack dump. Is this a regression? If so we might want to add the "breaking" tag to the changelog.

igamigo · 2026-08-05T15:12:02Z

+/// Part of the transaction kernel's assertion message for a transaction that changes nothing.
+///
+/// The assertion carries a message rather than a code the executor exposes, so this is matched as
+/// text. It only decides whether an explanatory line is printed: if the kernel ever rewords it,
+/// the line stops appearing and nothing else changes.
+const EMPTY_TRANSACTION_ASSERTION: &str = "neither changed the account state";


I think we should be able to remove this and do something like

let is_empty_transaction = matches!( &e, ClientError::TransactionExecutorError( TransactionExecutorError::TransactionProgramExecutionFailed(exec_err), ) if ERR_EPILOGUE_EXECUTED_TRANSACTION_IS_EMPTY.matches_execution_error(exec_err) );

Which is still not great but at least it does not depend on substring matching against a local const.

marijamijailovic mentioned this pull request May 15, 2026

Support for remote account #2187

Draft

igamigo changed the title ~~Typed rendering for call output~~ feat(CLI): Typed rendering for call output May 15, 2026

igamigo requested review from Keinberger and igamigo May 15, 2026 14:42

igamigo requested a review from JereSalo May 19, 2026 19:07

marijamijailovic marked this pull request as draft May 25, 2026 12:10

Keinberger reviewed May 27, 2026

View reviewed changes

marijamijailovic force-pushed the pr/call-typed-rendering branch from a74dc47 to 927cc8f Compare May 31, 2026 19:00

igamigo reviewed Jun 11, 2026

View reviewed changes

marijamijailovic force-pushed the pr/call-typed-rendering branch from 5c1cb85 to 69c7a49 Compare June 20, 2026 10:57

marijamijailovic changed the base branch from next to main June 20, 2026 12:40

marijamijailovic mentioned this pull request Jun 20, 2026

Debug info encoder decoder 0xMiden/miden-vm#3276

Open

marijamijailovic added 2 commits July 24, 2026 10:20

Typed rendering for call output

0b49c19

cLi call-rename module,resolve procedure via manifest,debug types tests

0ddccce

marijamijailovic added 2 commits July 24, 2026 10:20

Fix integration test transfer: snake to kebab case

48b2cf5

feat(cli): render typed debug-info output in miden call

b7be8c3

Drop the local package_debug_info module and consume the typed encoder/decoder from miden-mast-package's debug_info::typed instead.

feat(cli): read argument and result types from the package manifest

707e7cd

marijamijailovic force-pushed the pr/call-typed-rendering branch from 69c7a49 to 707e7cd Compare July 29, 2026 22:17

marijamijailovic added 2 commits July 30, 2026 12:48

Use miden-vm patch branch instead of a pinned rev

cbba9ae

Fix lint check

7ebbf1f

marijamijailovic changed the base branch from main to next August 1, 2026 12:39

igamigo reviewed Aug 5, 2026

View reviewed changes

Uh oh!

Conversation

marijamijailovic commented May 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marijamijailovic commented May 14, 2026

Uh oh!

igamigo commented May 15, 2026

Uh oh!

igamigo commented May 15, 2026

Uh oh!

marijamijailovic commented May 25, 2026

Uh oh!

Keinberger left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Keinberger May 27, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

marijamijailovic commented Jun 1, 2026

Uh oh!

marijamijailovic commented Jun 4, 2026

Uh oh!

marijamijailovic commented Jun 9, 2026

Uh oh!

igamigo left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

igamigo Jun 11, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

igamigo Jun 11, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

marijamijailovic commented Jun 12, 2026

Uh oh!

igamigo commented Jun 12, 2026

Uh oh!

marijamijailovic commented Jun 18, 2026

Uh oh!

marijamijailovic commented Jun 20, 2026

Uh oh!

marijamijailovic commented Jun 20, 2026

Uh oh!

igamigo commented Jun 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

marijamijailovic commented Jun 23, 2026

Uh oh!

igamigo commented Jul 22, 2026

Uh oh!

marijamijailovic commented Jul 23, 2026

Uh oh!

bitwalker commented Jul 28, 2026

Uh oh!

igamigo left a comment

Choose a reason for hiding this comment

Uh oh!

igamigo Aug 5, 2026

Choose a reason for hiding this comment

Uh oh!

igamigo Aug 5, 2026

Choose a reason for hiding this comment

Uh oh!

igamigo Aug 5, 2026

Choose a reason for hiding this comment

Uh oh!

igamigo Aug 5, 2026

Choose a reason for hiding this comment

Uh oh!

marijamijailovic commented May 13, 2026 •

edited

Loading

Keinberger left a comment •

edited

Loading

igamigo commented Jun 22, 2026 •

edited

Loading