[1/x] Pass an account as a parameter to note and tx script

[greenhat]

Close #787

This PR refactors the generate! macro to call wit-bindgen directly instead of using its generate! macro, and introduces an Account wrapper struct that aggregates methods from imported interfaces.

Changes

generate! macro refactoring

• Replaced the wit_bindgen::generate! macro invocation with direct calls to wit-bindgen-core and wit-bindgen-rust libraries
• This enables post-processing of generated bindings before emitting them

Account wrapper struct

• The generate! macro now automatically generates an Account struct in the bindings module
• This struct aggregates all public functions from imported WIT interfaces as methods
• Methods delegate to the original free functions in leaf modules

Script macros (#[note_script], #[tx_script])

• Now accept an optional second parameter of type Account
• The parameter is instantiated via Default::default() and passed to the user's run function
• Example: fn run(arg: Word, account: Account) { ... }

Misc

• Added collision detection for method names across different interfaces with clear error messages
• Extracted manifest path resolution into a new manifest_paths module

Example

Before:

use crate::bindings::miden::basic_wallet::basic_wallet::receive_asset;

#[note_script]
fn run(_arg: Word) {
    receive_asset(asset);
}

After:

use crate::bindings::Account;

#[note_script]
fn run(_arg: Word, account: Account) {
    account.receive_asset(asset);
}

[greenhat]

@bobbinth I'm wrapping up. Everything that we planned came out nicely. See the PR description and P2ID note at https://github.com/0xMiden/compiler/blob/50d6dce591144d0d0dc012344ee848eee8163e9b/examples/p2id-note/src/lib.rs?plain=1

I changed only two things:

1. Fixed Account name for the generated struct since we plan to merge all account component functions into it.
2. The run argument order. I want to make Account the first argument later. After we migrate new project templates and examples to use Account.

[bobbinth]

Looks great! Thank you! A couple of questions:

• In the linked example, on line 21, should it be account.id() - or is this note implemented yet?
• How does line use crate::bindings::Account know that Account is a basic wallet? (i.e., where do we specify this)

[greenhat]

Looks great! Thank you! A couple of questions:

• In the linked example, on line 21, should it be account.id() - or is this note implemented yet?

It's implemented in the next PR #801. See the new p2id code at

compiler/examples/p2id-note/src/lib.rs

Line 21 in adfb610

let current_account = account.get_id();

• How does line use crate::bindings::Account know that Account is a basic wallet? (i.e., where do we specify this)

I decided to forgo asking users about the account components. My line of thinking was that the note script can have only account components as dependencies. So, whatever account components generated bindings (free functions in modules) are, we will gather them all as methods in the Account struct. So for the developer the Account here is whatever they list in the note script dependencies fused under one struct. /cc @bitwalker what do you think?

[bobbinth]

I decided to forgo asking users about the account components. My line of thinking was that the note script can have only account components as dependencies. So, whatever account components generated bindings (free functions in modules) are, we will gather them all as methods in the Account struct. So for the developer the Account here is whatever they list in the note script dependencies fused under one struct.

Makes sense! I think this approach works - though, we should document this somewhere very clearly (otherwise it might feel like there is too much magic happening).

[greenhat]

I decided to forgo asking users about the account components. My line of thinking was that the note script can have only account components as dependencies. So, whatever account components generated bindings (free functions in modules) are, we will gather them all as methods in the Account struct. So for the developer the Account here is whatever they list in the note script dependencies fused under one struct.

Makes sense! I think this approach works - though, we should document this somewhere very clearly (otherwise it might feel like there is too much magic happening).

Sure. Besides the comments in macro code I explained the reason in the doc comments of the Account itself at c6f1259