dyn-abi is poorly tested. We should port the tests

          the tests that need to be ported are in `sol-type` 

encoder
decoder

Originally posted by @prestwich in #75 (comment)

Wrap the visitor macro impl with paste::paste! {} and wrap function names: [<visit_... $(_ $mut)?>]

port from ethers-rs

Blockers

• License review
• #13
• Finalize crate names
• #14
• Docs review
• #29
• port any upstream (reth) rlp changes
• #30
• #32
• depend on main ruint
• rename crates to final names below

pre-pub actions

• grab names on crates.io

pub

• release ethers-rlp to crates.io

Post pub

• #12
• ethers-rlp support in official ruint
• migrate to official ruint (blocks primitives publishing)

Can users use .into() the way they'd expect

          I'll refactor this file after this is merged, it's also getting pretty big

Originally posted by @DaniPopes in #83 (comment)

There is nothing done at run-time, so it should be a compile-time constant

Component

json-abi

Describe the feature you would like

Add a borrowed version of all json-abi types, which implement ToOwned. Ideally methods are implemented only once, with the owned version implementing Deref towards the borrowed type, but this might not be fully doable.

This might also allow declaring the entire ABI as a const/static by setting the lifetime to 'static.

Additional context

Refs: #136

This is a tracking issue for missing sol! proc macro (and corresponding sol-types, syn-solidity) features.

Blockers

• #68
• #38
• #55
• #73

Nice-to-haves

• #36
• #37
• #39
• #82
• #163
• #157, #184
• #254
• #261

• Add address to primitives
  • parsing w/ and w/o checksum
  • hexification w/ and w/o checksum
• Update ABI crates to use Address instead of B160

          > But we're cloning the data to get the inner tuple, so this is not ideal

I'm gonna think about this a bit more. what do you think of this:

trait SolType {

    type BorrowAbstraction: From<Self::RustType>;

    fn encode<T: Into<Self::BorrowAbstraction>>(t: T)

}

pub enum TupleBorrowAbstraction<'t, 'u, T, U> {
    Owned((T,U)),
    Borrowed(&'t (T, U)),
    MembersBorrowed((&'t T, &'u U))
}

// From impls here

Originally posted by @prestwich in #83 (comment)

• parses inner items like Input, minus lone Types and other contracts. Needs also adjusting logic for resolving stuff recursively inside of it too
• expands all inner items + a enum with all of the contract's functions (and one for events when supported). Traits implemented TBD
• add tests in sol-types/tests/doc_contracts.rs and UI tests

SolError and SolFunctionCall would be awesome

Benchmark from #57, as of commit 64bf519:

ethabi/encode/single    time:   [82.202 ns 82.358 ns 82.525 ns]                                 
ethabi/encode/struct    time:   [164.10 ns 165.43 ns 166.85 ns]                                 

ethabi/decode/word      time:   [34.678 ns 34.765 ns 34.861 ns]                                
ethabi/decode/dynamic   time:   [78.638 ns 78.759 ns 78.910 ns]                                  

dyn-abi/encode/single   time:   [68.373 ns 68.550 ns 68.741 ns]                                  
dyn-abi/encode/struct   time:   [683.96 ns 684.70 ns 685.52 ns]                                   

dyn-abi/decode/word     time:   [54.141 ns 54.203 ns 54.266 ns]                                
dyn-abi/decode/dynamic  time:   [80.822 ns 80.932 ns 81.053 ns]                                   

sol-types/encode/single time:   [42.843 ns 43.007 ns 43.207 ns]                                     
sol-types/encode/struct time:   [49.110 ns 49.171 ns 49.235 ns]                                    

sol-types/decode/word   time:   [1.3375 ns 1.3389 ns 1.3405 ns]                                   
sol-types/decode/dynamic                                                                             
                        time:   [39.279 ns 39.478 ns 39.721 ns]

Maybe we can skip tokenizing by encoding directly the DynSolValue? Looking at the "struct" bench, ethabi is much more concise because of ethabi::encode(tokens: &[ethabi::Token]), while dyn-abi has to declare all the types, and then also clone the input on each call.

Originally posted by @DaniPopes in #57 (comment)

Use cargo workspace deps

This code:

https://github.com/ethers-rs/core/blob/23962043923bd859881e1c0021822641763e1564/crates/abi/src/types/struct.rs#L108-L112

Needs #102

https://github.com/rust-ethereum/ethabi/tree/master/ethabi/src

Component

sol-type

What version of Alloy are you on?

No response

Operating System

macOS (Apple Silicon)

Describe the bug

(de)Tokenization logic does not properly handle ints whose length is different from the rust type's length. causes panic in the copy_from_slice in the macro

    #[test]
    fn tokenizing_int_sizes() {
        Uint::<24>::tokenize(&1u32);

        let word: [u8; 32] = (0..32).collect::<Vec<u8>>().try_into().unwrap();
        let word: WordToken = word.into();

        assert_eq!(Uint::<24>::detokenize(word), 126495);
    }```

Component

sol! macro

What version of Alloy are you on?

v0.2.0

Operating System

Linux

Describe the bug

I think the problem is related to deposit taking in no arguments.

use alloy_sol_types::{sol, SolCall};

sol! {
    interface WETH {
        function deposit() external payable;
    }
}

fn main() {
    WETH::depositCall::decode(&WETH::depositCall::SELECTOR, true).expect("it should work");
}

Should #[repr(u8)], add convert functions and impl SolType (new SolEnum trait?)

Component

syn-solidity

Describe the feature you would like

Listed in the description of #119

Additional context

No response

Needs #72.

• Add inner attributes to File
  • Parse #[sol(...)] attributes, maybe #![sol(include = "path/to/abi.json")]
• Parse included JSON string as dynamic JSON ABI
• Generate a Solidity interface string
• Parse Solidity interface string into a TokenStream, and call sol

          should we rename to `canonical_type` to match solidity spec?

Originally posted by @prestwich in #104 (comment)

          To consider: should we error if there are too many topics in the iterator?

Originally posted by @prestwich in #83 (comment)

Like iterators from ethabi::*

Component

No response

Describe the feature you would like

Exported macro_rules! that wrap hex_literal::hex! with $crate::<type> constructors. Also re-export hex! itself

Additional context

No response

currently the type field is unparsed, while ethabi users expect a parsed ParamKind enum. This would also remove the intermediate enum between the {Simple,Complex} structs

Component

sol-type, sol! macro

Describe the feature you would like

Currently we generate a ContractErrors enum, which is fine for custom errors but cannot be used to also decode Solidity panics and reverts.
We should provide some way to easily decode all of the above in one method

Additional context

No response

Component

sol-type, sol! macro

Describe the feature you would like

Additional context

No response

Support ABI, and parsing it from JSON. Like ethabi::Contract.
cc @prestwich

• SolEvent trait
• sol! support, similar implementation to error.rs

compilation requires the feature to be selected, whether via dep or dev-dep. All consuming libraries using wasm must set this feature in deps or dev-deps

Port serde_helpers from old ethers, as a new crate ethers-serde

type_data_size multiples array length by inner_size, which will incorrectly calculate lengths and incorrectly inner_size expressions.

https://github.com/alloy-rs/core/blob/main/crates/sol-macro/src/expand/type.rs#L159-L179

blocker for #85

current behavior:

    struct Foo {
        address[] baz;
    }

    /// Nested struct.
    struct Nested {
        Foo[2] a;
    }

produces code like this:

            0usize
                + 2usize * (0usize + 32usize + 64usize + self.a.baz.len() * (32usize))

correct behavior:

            0usize
                + self.a.iter().map( |element| /* inner size expression for element */ ).sum::<usize>()

2 incorrect things:

• assumes all array elements of Foo.a are the same size
• because there's no iteration, it does not index `self.a[0].baz.len()'

both of these would be resolved using an iter in the expansion

Custom types are Solidity paths, and currently we panic if it's longer than 1 ident.

          I think this can be done in another PR, since we don't handle any type of function (constructor, fallback...) other than literally `function`

Originally posted by @DaniPopes in #153 (comment)

Similar to the way error & panic are included in the base lib, we should consider including fallback and receive as hard-coded types. This requires special handling, as they have no selector

Rename SolError::Tuple to SolError::Parameters, SolCall::Tuple to SolCall::Arguments

Component

No response

What version of Alloy are you on?

No response

Operating System

None

Describe the bug

No response

Component

No response

Describe the feature you would like

have sol! generate SolCall structs for auto-generated getters for storage vars and mappings

Additional context

No response