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

bpf2go: ergonomic enums #1636

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

bpf2go: ergonomic enums #1636

wants to merge 2 commits into from

Conversation

mejedi
Copy link
Contributor

@mejedi mejedi commented Dec 20, 2024

Constant names emitted for enum elements end up quite unwieldy. They are
prefixed with enum name because in C struct, union and enum names are in
a separate namespace, allowing for overlaps with identifiers, e.g:

enum E { E };

While such overlaps are possible in theory, people usually don't do
it. If a typicall C naming convention is followed, we get

enum something {
    SOMETHING_FOO, SOMETHING_BAR
};

generating <STEM>SomethingSOMETHING_FOO and <STEM>SomethingSOMETHING_BAR.

In addition to "safe" long names, generate shorter ones if the
respective name is not taken. <STEM>SOMETHING_FOO and
<STEM>SOMETHING_BAR are much nicer to work with.

@mejedi mejedi changed the title Ergonomic enums bpf2go: Ergonomic enums Dec 20, 2024
@mejedi mejedi requested a review from ti-mo December 20, 2024 13:05
bpf2go orders generated types by name to ensure the output is stable.
Adjust data structures such that we can rely on implicit sorting in
text/template, removing sortTypes alltogether.

The added reservedNames hash is handy for rejecting "reserved" type names
such as "<STEM>Specs", and for the upcoming "ergonomic" enum feature
(generate short names for enum members if not yet taken).

Signed-off-by: Nick Zavaritsky <[email protected]>
Constant names emitted for enum elements end up quite unwieldy. They are
prefixed with enum name because in C struct, union and enum names are in
a separate namespace, allowing for overlaps with identifiers, e.g:

enum E { E };

While such overlaps are possible in *theory*, people usually don't do
it. If a typicall C naming convention is followed, we get

enum something {
    SOMETHING_FOO, SOMETHING_BAR
};

generating <STEM>SomethingSOMETHING_FOO and <STEM>SomethingSOMETHING_BAR.

In addition to "safe" long names, generate shorter ones if the
respective name is not taken. <STEM>SOMETHING_FOO and
<STEM>SOMETHING_BAR are much nicer to work with.

Signed-off-by: Nick Zavaritsky <[email protected]>
@mejedi mejedi changed the title bpf2go: Ergonomic enums bpf2go: ergonomic enums Dec 20, 2024
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.

1 participant