Skip to content

Allow blocklisting anonymous enums #3067

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

jschwe
Copy link
Contributor

@jschwe jschwe commented Jan 6, 2025

Currently, there is no way to blocklist anonymous enums, which is inconvenient if you want to avoid _bindgen_tyXX types appearing in the public API.

Note: I'm not 100% sure if this is the best place to apply the blocklisting, but I couldn't find a more appropriate place.

@jschwe jschwe force-pushed the jschwender/blocklist_anon_enums branch from 05c2885 to 1d01b94 Compare January 6, 2025 08:06
@jschwe jschwe force-pushed the jschwender/blocklist_anon_enums branch from b87010a to 3b5da54 Compare February 4, 2025 20:26
{
debug!("Blocklisting anonymous enum.");
return;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't this only block the enum if all variants, and not any are blocklisted? If not, can we document this behavior and why is it useful? thanks.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The behavior of using any variant matches for anonymous enums is not new, and already works when allowlisting anonymous enums, so there is a (probably small) risk that changing the way matching works could break users who are relying on the current behavior for allowlisting.

Copy link
Contributor

Choose a reason for hiding this comment

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

But you can individually hide variants (via annotations or callbacks), right...

I'd expect allowlisting to work with any and blocklisting to work with all, if that makes sense... But let me know if you disagree, maybe my expectation is flawed somehow?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, I think that's perfectly reasonable. I changed this PR to use all instead. This will also block all anonymous enums without variants (See my comment on test 1025 below).

@jschwe jschwe force-pushed the jschwender/blocklist_anon_enums branch 2 times, most recently from e901c73 to 8bb3e15 Compare April 25, 2025 08:22
Note: This will also block anonymous enums with no variants, but
adding a typedef for such an enum should be useless anyway.
@jschwe jschwe force-pushed the jschwender/blocklist_anon_enums branch from 8bb3e15 to 4ea949f Compare April 25, 2025 08:31
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I looked into #1025 and I'm assuming that the anonymous enum with no variants was just an example and nobody actually needs a typedef for an anonymous enum with no variants (which would be blocked by this PR, unless we specifically want to preserve existing behavior, since .all() in Rust returns true if there is nothing to iterate over).

I added some cases for the other possibilities and the typedef is still generated correctly for all the enum definitions that could be used in some way.
CC @ctaggart who reported #1025, just in case I'm missing something and they had an actual usecase for a typedef for an anonymous enum with no variants.

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.

2 participants