Skip to content

fixed some function pointer naming scheme bug. also hacked a fix for bitmask / bitflags naming discrepency.#1

Open
jedjoud10 wants to merge 1 commit into
BitSyndicate1:rewrite-buildersfrom
jedjoud10:rewrite-builds-tmp-2-idk
Open

fixed some function pointer naming scheme bug. also hacked a fix for bitmask / bitflags naming discrepency.#1
jedjoud10 wants to merge 1 commit into
BitSyndicate1:rewrite-buildersfrom
jedjoud10:rewrite-builds-tmp-2-idk

Conversation

@jedjoud10
Copy link
Copy Markdown

For the p/pp function pointer issue:
I have added an extra function in RustTranslator that simply trims the p_ or pp_ prefixes (this isn't an issue for function argument names but it is for function names themselves, which the previously manually written extension implementations depended on.) There was also an issue where there would be duplicate function names after this trimming step (which happened because there were functions like p_usage_counts and pp_usage_counts on the same struct, iirc it was for the opacity micromap extension). Simplest fix for this was to add a exception for pp_usage_count and pp_geometries and instead rename them to usage_count_ptrs and geometries_ptrs. I think I said something about this on your PR on Friz64's fork.

For the bitmask / bitflags issue:
I have "resolved" a compilation issue with the previously hand-written wrapper impls (using the previous generator), because all FPs take in arguments of type *FlagBits (for example DebugUtilsMessageSeverityFlagBitsEXT). However the public API (and the handwritten implementations) take in arguments of the nomenclature *Flags (for example DebugUtilsMessageSeverityFlagsEXT).

I have come up with a quick hack to remedy this. it calls a duplicate of type_to_rust from RustTranslator, but prior to converting to an identifier it just does a quick str replace. The reason for duplicating this is because during generation in bitmasks.rs, we would want to keep the "unreplaced" variant. Ofc this replacement logic could have been done there but since TypeName expects a &'static str I can't think of a way to create a new TypeName to pass to type_to_rust that upholds that requirement. This led me to do this ugly hack but it definitely works. Seems like the prev generator did something similar with a replace call as well.

This is what I mean by "hand-written functions" (from debug_utils.rs).

It is ugly but I am unsure of another way to do this without having to change the type definition of TypeName to accomodate non 'static strs.

Please let me know if this is good or not :)

(P.S I wonder if it is possible to .gitignore the generated code for now that way we can avoid generating large commits every time we have to change the generator. We could un-gitignore it after we are sure that it works properly with everything completed)

…bitmask / bitflags naming discrepency.

both of these were required for proper compilation of the hand written impls for extensions. they still do not compile on my branch but these fixes are something at least.
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