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: SolEnum and SolInterface #153

Merged
merged 22 commits into from
Jun 30, 2023
Merged

feat: SolEnum and SolInterface #153

merged 22 commits into from
Jun 30, 2023

Conversation

DaniPopes
Copy link
Member

@DaniPopes DaniPopes commented Jun 26, 2023

Motivation

Closes #37
Closes #106

Solution

PR Checklist

  • Added Tests
  • Added Documentation
  • Breaking changes

Revert(Revert),
/// A panic. See [`Panic`] for more information.
Panic(Panic),
}
Copy link
Member

@prestwich prestwich Jun 26, 2023

Choose a reason for hiding this comment

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

Should there be an empty variant? for data-less reverts

Copy link
Member Author

Choose a reason for hiding this comment

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

Makes sense

Copy link
Member Author

@DaniPopes DaniPopes Jun 27, 2023

Choose a reason for hiding this comment

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

This just kinda breaks the entire thing, since now we can't assume that data has a selector. I'm not sure how to do this, I think it's better we don't include this.
Same for fallback functions etc.

Copy link
Member

Choose a reason for hiding this comment

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

yeah, I guess the question is whether we want this trait/enum to capture:

  1. ALL inputs and outputs (known ABI & unknown ABI & Empty)
  2. NON-EMPTY inputs and outputs (known ABI & unknown ABI)
  3. KNOWN inputs and outputs (known ABI & Empty)
  4. KNOWN & NON-EMPTY inputs and outputs (known ABI only)

Right now we have option 4. Do we have a plan for capturing the remainder?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm thinking 4 is fine for now, maybe 3 in the future. I don't want to overload this PR

Copy link
Member

Choose a reason for hiding this comment

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

how do we capture the other 2 categories using this trait? Something like this?

pub enum Revert<T: SolCalls >{
    Known(T),
    UnknownAbi(Vec<u8>)
    Bare(Vec<u8>)
    Empty
}

crates/sol-macro/src/expand/mod.rs Outdated Show resolved Hide resolved
crates/sol-types/tests/ui/type.stderr Outdated Show resolved Hide resolved
@DaniPopes DaniPopes changed the title feat: SolEnum and SolCalls feat: SolEnum and SolInterface Jun 29, 2023
crates/sol-macro/src/expand/contract.rs Outdated Show resolved Hide resolved
crates/sol-macro/src/expand/contract.rs Outdated Show resolved Hide resolved
@@ -87,7 +90,7 @@ pub enum ContractError<T> {
Panic(Panic),
}

impl<T: SolCalls> SolCalls for ContractError<T> {
impl<T: SolInterface> SolInterface for ContractError<T> {
Copy link
Member

Choose a reason for hiding this comment

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

this allows accidentally mixing calls and errors, yeah?

ContractError<MyContractCalls> is valid, as is ContractError<MyContractErrors>

is there a way to fix this in the type system?

Copy link
Member Author

Choose a reason for hiding this comment

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

Would either require a generic or assoc type which implements Sol*, but idk.
I'd also like to not have different traits for the event enum with something like type Selector = [u8; _] but not sure if doable.
I'd leave this for later since it's not that big of a deal.

Copy link
Member

Choose a reason for hiding this comment

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

should we have a trait to capture this somehow?

trait SelectorPrefixed {}
trait SolError: SelectorPrefixed {}

that sort of thing?

/// pub fn #is_variant,#as_variant,#as_variant_mut(...) -> ... { ... }
/// )*
/// }
/// ```
Copy link
Member

Choose a reason for hiding this comment

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

this is a good refactor 😍

}

fn expand_event(self, attrs: &[Attribute]) -> TokenStream {
// TODO: SolInterface for events
Copy link
Member

Choose a reason for hiding this comment

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

capture in an issue as this needs some conceptualizing I think? 🤔

Copy link
Member

@prestwich prestwich left a comment

Choose a reason for hiding this comment

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

this is huge. we should get it in and then capture remaining work items as issues

@DaniPopes DaniPopes merged commit 9e01fd2 into main Jun 30, 2023
18 checks passed
@DaniPopes DaniPopes deleted the dani/sol-events branch June 30, 2023 22:09
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.

[Feature] Convenient way to decode a contract error Add sol! support for enums
3 participants