[ffigen] Remove Writer.usedEnumCTypes #2521
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Part of a larger refactor where I'm trying to make
Writer
less stateful during code gen. Currently there's a lot of stuff that should be implemented using visitors that is actually tracked by a bit ofWriter
state during codegen. End goal is to make the type to string conversion functions takeContext
instead ofWriter
.usedEnumCTypes
is only used to generate a warning message when enums are passed through FFI APIs, because doing so is unsafe (different C compilers treat enums differently).The old logic added the enum to
usedEnumCTypes
when itsgetCType
method was called during code generation. The enum's own generated bindings don't usegetCType
, only other bindings that refer to the enum call this method (eg when passing an enum as a function param). So this was a roundabout (and brittle) way of checking if the enum is used in any APIs. If we later decided to usegetCType
in the enum's own bindings, this check would start producing a ton of false positives.A more direct approach is just to run a visitor from all non-enum bindings and see if we find any enums.
Part of #2462 and #1259
This is also yak shaving for #2419
The CI failure is unrelated: #2517