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.

Sign up for GitHub

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

Jump to bottom

Remove derive_more #1600

Merged
merged 7 commits into from
May 24, 2024
Merged

Remove derive_more #1600

merged 7 commits into from
May 24, 2024

Conversation

pkhry
Copy link
Contributor

@pkhry pkhry commented May 21, 2024 •
edited
Loading

Description

  • I decided to define a macro for Error wrapping to use in place of From from derive_more
  • Reimplemented Display by hand.
  • also removed derive_more from dependencies

Questions:

Given that we used derive_more for errors, maybe we can use SNAFU for errors with no-std constraint given that thiserror doesn't support no-std
see #1503

@pkhry pkhry requested a review from a team as a code owner May 21, 2024 16:40
jsdw
jsdw reviewed May 22, 2024
View reviewed changes
core/src/macros.rs Outdated Show resolved Hide resolved
jsdw
jsdw reviewed May 22, 2024
View reviewed changes
signer/src/utils.rs Outdated Show resolved Hide resolved
jsdw
jsdw reviewed May 22, 2024
View reviewed changes
core/src/error.rs Outdated Show resolved Hide resolved
@pkhry pkhry requested a review from jsdw May 22, 2024 11:02
@jsdw
Copy link
Collaborator

jsdw commented May 22, 2024

Feel free to merge the two sub-PRs into this one; IMO it would be easier to see it all in one place, and you'll have to merge the others into here before we can properly review this one anyway!

I think I'd only normally stick to separate PRs when it's actually two distinct things that can both be merged to master independently :)

@pkhry pkhry changed the title Remove derive_more's From usages Remove derive_more May 22, 2024
@pkhry
Copy link
Contributor Author

pkhry commented May 22, 2024

Feel free to merge the two sub-PRs into this one; IMO it would be easier to see it all in one place, and you'll have to merge the others into here before we can properly review this one anyway!

I think I'd only normally stick to separate PRs when it's actually two distinct things that can both be merged to master independently :)

I initially made separate pr's to make reviewing easier, but good to know, i won't be splitting mr's in the future if they are changing the same thing

niklasad1
niklasad1 reviewed May 22, 2024
View reviewed changes
signer/src/eth.rs Outdated Show resolved Hide resolved
niklasad1
niklasad1 reviewed May 22, 2024
View reviewed changes
core/src/error.rs Outdated
Error::Decode(value.into())
}
}
convert_error!(ExtrinsicParamsError as Error::ExtrinsicParams);
Copy link
Member

@niklasad1 niklasad1 May 22, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

What do you think about:

impl_from!(ExtrinsicParamsError => Error::ExtrinsicParams);

I find "as" slightly misleading because in my head as == typecast such as "usize::MAX as u64"....

Ideally we could find a similar crate as derive_more or some other crate for error handling where it supports opting out from std::error::Error which is the reason why we are not using thiserror in subxt but this should work as work around for now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

changed convert_from to impl_from with the as -> => swap

@pkhry pkhry mentioned this pull request May 22, 2024
Closed
lexnv
lexnv approved these changes May 23, 2024
View reviewed changes
Copy link
Collaborator

@lexnv lexnv left a comment

Choose a reason for hiding this comment

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

LGTM! I do like the suggestion from Niklas to have a impl_from instead of convert_err

jsdw
jsdw approved these changes May 23, 2024
View reviewed changes
Copy link
Collaborator

@jsdw jsdw left a comment

Choose a reason for hiding this comment

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

Nice, LGTM! (I'd also be up for that impl_from and => thing but easy either way :)

@pkhry pkhry requested a review from niklasad1 May 23, 2024 17:26
pkhry and others added 6 commits May 23, 2024 19:43
@pkhry
replace derive_more's 'From' in signer
518db9a
@pkhry
replace derive_more's 'From' in core
527f673
@pkhry
Remove derive_more's Display usages (#1601)
49fe0e6 
* Remove derive_more's 'Display' from core

* Remove derive_more's 'Display' from metadata

* Remove derive_more's 'Display' from signer

* Remove derive_more from dependencies (#1602)

closes #1503
@pkhry @niklasad1
Update signer/src/eth.rs
aa132b9 
Co-authored-by: Niklas Adolfsson <niklasadolfsson1@gmail.com>
@pkhry
rename convert_error to impl_from
c474c27
@pkhry
rename convert_error to impl_from in core
e6b6394
@niklasad1 niklasad1 merged commit 5a0682c into master May 24, 2024
13 checks passed
@niklasad1 niklasad1 deleted the pkhry/derive_more_from branch May 24, 2024 09:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@lexnv lexnv lexnv approved these changes

@niklasad1 niklasad1 niklasad1 approved these changes

@jsdw jsdw jsdw approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@pkhry @jsdw @niklasad1 @lexnv