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

Derive StorageAccess for EthAddress and abi Dispatcher builtin types #3247

Conversation

maciejka
Copy link
Contributor

@maciejka maciejka commented May 26, 2023

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


This change is Reviewable

Copy link
Collaborator

@orizi orizi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

#[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.

Copy link
Collaborator

@orizi orizi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

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

StorageAccess derivation optimization: #3259

@maciejka maciejka changed the title Derive StorageAccess for builtin types Derive StorageAccess for EthAddress and abi Dispatcher builtin types May 31, 2023
Copy link
Collaborator

@orizi orizi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

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

Copy link
Collaborator

@orizi orizi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@spapinistarkware spapinistarkware left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

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

@spapinistarkware spapinistarkware added this pull request to the merge queue May 31, 2023
Merged via the queue into starkware-libs:main with commit e15d173 May 31, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants