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
Conversation
…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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
For the p/pp function pointer issue:
I have added an extra function in
RustTranslatorthat simply trims thep_orpp_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 likep_usage_countsandpp_usage_countson the same struct, iirc it was for the opacity micromap extension). Simplest fix for this was to add a exception forpp_usage_countandpp_geometriesand instead rename them tousage_count_ptrsandgeometries_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 exampleDebugUtilsMessageSeverityFlagBitsEXT). However the public API (and the handwritten implementations) take in arguments of the nomenclature*Flags(for exampleDebugUtilsMessageSeverityFlagsEXT).I have come up with a quick hack to remedy this. it calls a duplicate of
type_to_rustfromRustTranslator, but prior to converting to an identifier it just does a quick str replace. The reason for duplicating this is because during generation inbitmasks.rs, we would want to keep the "unreplaced" variant. Ofc this replacement logic could have been done there but sinceTypeNameexpects a&'static strI can't think of a way to create a newTypeNameto pass totype_to_rustthat upholds that requirement. This led me to do this ugly hack but it definitely works. Seems like the prev generator did something similar with areplacecall 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
TypeNameto accomodate non'staticstrs.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)