Derive StorageAccess for EthAddress and abi Dispatcher builtin types

[maciejka]

Derive StorageAccess impl for Starknet builtin types: u256, EthAddress, Dispatcher using derive(storage_access::StorageAccess)

---

This change is 

[orizi]

Reviewable status: 0 of 10 files reviewed, 3 unresolved discussions (waiting on @maciejka)

---

corelib/src/integer.cairo line 929 at r1 (raw file):

}

#[derive(Copy, Drop, PartialEq, Serde, storage_access::StorageAccess)]

this implementation is less efficient than the original - for core types i'd rather incur the extra implementation cost than the overhead.

Code quote:

, storage_access::StorageAccess

---

corelib/src/starknet/eth_address.cairo line 14 at r1 (raw file):

    fn try_into(self: felt252) -> Option<EthAddress> {
        // TODO(yuval): change to a constant once u256 literals are supported.
        let ETH_ADDRESS_BOUND = 1461501637330902918203684832716283019655932542976_u256; // 2 ** 160

Suggestion:

0x10000000000000000000000000000000000000000

---

crates/cairo-lang-starknet/src/plugin/dispatcher.rs line 166 at r1 (raw file):

            struct {library_caller_name} {{
                class_hash: starknet::ClassHash,
            }}

adding these as storage access seems kinda weird to me - although i understand the sentiment.
@spapinistarkware WDYT?

Code quote:

            #[derive(Copy, Drop, storage_access::StorageAccess)]
            struct {contract_caller_name} {{
                contract_address: starknet::ContractAddress,
            }}

            impl {contract_caller_name}Impl of {dispatcher_name}::<{contract_caller_name}> {{
            $contract_caller_method_impls$
            }}

            #[derive(Copy, Drop, storage_access::StorageAccess)]
            struct {library_caller_name} {{
                class_hash: starknet::ClassHash,
            }}

[maciejka]

#[derive(Copy, Drop, PartialEq, Serde, storage_access::StorageAccess)]

this implementation is less efficient than the original - for core types i'd rather incur the extra implementation cost than the overhead.

Because is uses read/write_at_offset_internal instead of read/write for the first field?
It should be possible to make derive(, storage_access::StorageAccess) generate code that is as efficient as manually generated one.

[orizi]

so do so - and only after move to this impl.

Reviewed 2 of 10 files at r1.
Reviewable status: 2 of 10 files reviewed, 2 unresolved discussions (waiting on @maciejka)

[maciejka]

so do so - and only after move to this impl.

StorageAccess derivation optimization: #3259

[orizi]

Reviewed 9 of 10 files at r2, all commit messages.
Reviewable status: 9 of 10 files reviewed, all discussions resolved (waiting on @maciejka)

[orizi]

Reviewed 1 of 10 files at r2.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @maciejka)

[spapinistarkware]

Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @maciejka)