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

rlp/rlpgen: remove build tag #28106

Merged
merged 2 commits into from
Sep 14, 2023
Merged

rlp/rlpgen: remove build tag #28106

merged 2 commits into from
Sep 14, 2023

Conversation

fjl
Copy link
Contributor

@fjl fjl commented Sep 13, 2023

This tag was supposed to prevent unstable output when types reference each other. Imagine there are two struct types A and B, where a reference to type B is in A. If I run rlpgen on type B first, and then on type A, the generator will see the B.EncodeRLP method and call it. However, if I run rlpgen on type A first, it will inline the encoding of B.

The solution I chose for the initial release of rlpgen was to just ignore methods generated by rlpgen using a build tag. But there is a problem with this: if any code in the package calls EncodeRLP explicitly, the package can't be loaded without errors anymore in rlpgen, because the loader ignores it. Would be nice if there was a way to just make it ignore invalid functions during type checking (they're not necessary for rlpgen), but golang.org/x/tools/go/packages does not provide a way of ignoring them.

Luckily, the types we use rlpgen with do not reference each other, so we can just remove the build tags for now.

Fixes #28008

This tag was supposed to prevent unstable output when types reference each other. Imagine
there are two struct types A and B, where a reference to type B is in A. If I run rlpgen
on type B first, and then on type A, the generator will see the B.EncodeRLP method and
call it. However, if I run rlpgen on type A first, it will inline the encoding of B.

The solution I chose for the initial release of rlpgen was to just ignore methods
generated by rlpgen using a build tag. But there is a problem with this: if any code in
the package calls EncodeRLP explicitly, the package can't be loaded without errors anymore
in rlpgen, because the loader ignores it. Would be nice if there was a way to just make it
ignore invalid functions during type checking (they're not necessary for rlpgen), but
golang.org/x/tools/go/packages does not provide a way of ignoring them.

Luckily, the types we use rlpgen with do not reference each other right now, so we can
just remove the build tags for now.
@fjl fjl added this to the 1.13.1 milestone Sep 13, 2023
Copy link
Contributor

@holiman holiman left a comment

Choose a reason for hiding this comment

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

LGTM

@fjl fjl merged commit 909dd4a into ethereum:master Sep 14, 2023
devopsbo3 pushed a commit to HorizenOfficial/go-ethereum that referenced this pull request Nov 10, 2023
* rlp/rlpgen: remove build tag

This tag was supposed to prevent unstable output when types reference each other. Imagine
there are two struct types A and B, where a reference to type B is in A. If I run rlpgen
on type B first, and then on type A, the generator will see the B.EncodeRLP method and
call it. However, if I run rlpgen on type A first, it will inline the encoding of B.

The solution I chose for the initial release of rlpgen was to just ignore methods
generated by rlpgen using a build tag. But there is a problem with this: if any code in
the package calls EncodeRLP explicitly, the package can't be loaded without errors anymore
in rlpgen, because the loader ignores it. Would be nice if there was a way to just make it
ignore invalid functions during type checking (they're not necessary for rlpgen), but
golang.org/x/tools/go/packages does not provide a way of ignoring them.

Luckily, the types we use rlpgen with do not reference each other right now, so we can
just remove the build tags for now.
devopsbo3 added a commit to HorizenOfficial/go-ethereum that referenced this pull request Nov 10, 2023
devopsbo3 added a commit to HorizenOfficial/go-ethereum that referenced this pull request Nov 10, 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.

Go generate failed
2 participants