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

Add abi.encodeError similarly to abi.encodeCall #14287

Open
Amxx opened this issue Jun 1, 2023 · 4 comments · May be fixed by #14974
Open

Add abi.encodeError similarly to abi.encodeCall #14287

Amxx opened this issue Jun 1, 2023 · 4 comments · May be fixed by #14974
Labels
feature low effort There is not much implementation work to be done. The task is very easy or tiny. low impact Changes are not very noticeable or potential benefits are limited. should have We like the idea but it’s not important enough to be a part of the roadmap.

Comments

@Amxx
Copy link

Amxx commented Jun 1, 2023

Abstract

Using abi.encodeCall for encoding errors fails with error

Error (3509): Expected regular external function type, or external view on public function. Cannot use errors for abi.encodeCall.

It would be nice to have a abi.encodeError that works similarly to abi.encodeCall, but for custom errors.

Motivation

Both functions and error include a .selector getter that returns the bytes4 "signature". In the case of a function selector, this can be used, along with abi.encodeWithSelector to generate the bytes corresponding to a function call. Similarly, abi.encodeWithSelector can be used to encode a custom error.

abi.encodeCall is a safer alternative that verifies the type and number or arguments at compile type. While abi.encodeCall works well with functions, it does not currently support errors.

Being able to generate the bytes corresponding to custom errors can be particularly usefull for testing with Foundry.

Specification

Given a custom error

error SomeErrorName(address arg0, uint256 arg1, bytes4 arg2, bytes32 arg3);

Enable the syntax

abi.encodeError(SomeErrorName, (arg0, arg1, arg2, arg3));

that returns the same as

abi.encodeWithSelector(SomeErrorName.selector, arg0, arg1, arg2, arg3);

with the same type checking as abi.encodeCall

Backwards Compatibility

None. This is introducing a new syntax that doesn't conflict with existing ones.

@github-actions
Copy link

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

@github-actions github-actions bot added the stale The issue/PR was marked as stale because it has been open for too long. label Aug 30, 2023
@ekpyron ekpyron removed the stale The issue/PR was marked as stale because it has been open for too long. label Aug 30, 2023
@ethereum ethereum deleted a comment Sep 8, 2023
Copy link

github-actions bot commented Dec 8, 2023

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

@github-actions github-actions bot added the stale The issue/PR was marked as stale because it has been open for too long. label Dec 8, 2023
@cameel cameel added low effort There is not much implementation work to be done. The task is very easy or tiny. low impact Changes are not very noticeable or potential benefits are limited. should have We like the idea but it’s not important enough to be a part of the roadmap. and removed stale The issue/PR was marked as stale because it has been open for too long. labels Dec 8, 2023
Copy link

This issue has been marked as stale due to inactivity for the last 90 days.
It will be automatically closed in 7 days.

@github-actions github-actions bot added the stale The issue/PR was marked as stale because it has been open for too long. label Mar 12, 2024
@ekpyron ekpyron removed the stale The issue/PR was marked as stale because it has been open for too long. label Mar 12, 2024
@Amxx
Copy link
Author

Amxx commented Apr 2, 2024

still relevant

@Amxx Amxx linked a pull request Apr 2, 2024 that will close this issue
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature low effort There is not much implementation work to be done. The task is very easy or tiny. low impact Changes are not very noticeable or potential benefits are limited. should have We like the idea but it’s not important enough to be a part of the roadmap.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants