Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add abigen! macro #475

Closed
wants to merge 34 commits into from
Closed

feat: add abigen! macro #475

wants to merge 34 commits into from

Conversation

glihm
Copy link
Contributor

@glihm glihm commented Sep 24, 2023

Here is the first draft for abigen! macro.

Issues

fixes #286
fixes #445

Usage

This macro aims at being used like:

// From a abi json file (path relative to Cargo.toml file).
abigen!(ContractName, "/path/abi.json");

// From a literal string containing the JSON. This one was more used for
// testing, perhaps not useful.
abigen!(ContractName, r#"
[{...}]
"#);

Code organization

The code is separated in 3 parts:

  1. cairo_types which contains the mapping of Cairo native types into rust types.
  2. parser contains all the logic to parse ABI as a JSON, where types are strings, and totally flatten. This is where the generic types are detected and applied to each member/variant or struct/enum.
  3. abigen contains the code logic related to macro expansion and code generation.

Examples

Two examples were added:

  1. abigen.rs contains the very basic usage working on testnet with user addresses.
  2. abigen_event.rs shows how abigen! facilitate the deserialization of events.

@glihm
Copy link
Contributor Author

glihm commented Sep 25, 2023

Just seen that ConnectedAccount trait offers a method to get the provider from the account.

Maybe we want two ways of initialize the contract:

// For calls only.
let contract = MyContract::new(address, provider);

// For invoke and calls.
let contract = MyContract::new_with_account(address, account);

And internally, we use the provider if present in case 1, or the one from the account in case 2.
Perhaps this will be easier for init. To be checked with Pia (can't tag here right now) as she working on the with_account design.

*** EDIT ***
reworked to now generate MyContract and MyContractReader. Having the reader included inside the MyContract implementation which is the one with account.

As we need the type match for deserialization,
the item path is expecting , which
fails if we pass a slice
interfaces define some functions that are exposed by the
contract. Can it be interesting to split them?
@glihm
Copy link
Contributor Author

glihm commented Oct 6, 2023

@xJonathanLEI let me know when you would have time for a first review, in order to keep going forward with this feature. 👍

I am exploring a new version where every interface in the ABI is implemented in a trait, this IMO can be helpful to easily switch targeted contracts without changing the actual code using them.

@glihm
Copy link
Contributor Author

glihm commented Oct 10, 2023

Other idea that may be interesting, we can add some option for the code generation. For instance, it can be useful sometimes to get access to the Call generated by an external, without sending the transaction. This can help when we only want to send one transaction, with several calls inside it.

@Eikix
Copy link

Eikix commented Nov 10, 2023

Hey:)! At Kakarot, we're super interested in such a feature, any ETA or reason why it shouldn't more forward for now?

@glihm
Copy link
Contributor Author

glihm commented Dec 1, 2023

Hey:)! At Kakarot, we're super interested in such a feature, any ETA or reason why it shouldn't more forward for now?

Hey! Currently re-working the code to enhance the proposal in this PR using Syn crate to parse types and enhancing devX following alloy nomenclature.

This will allow more flexibility on configuration for the calls and invokes.

@glihm glihm closed this Feb 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants