Refactoring Bindings Generator #215
Merged
Conversation
This file contains 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
…pace for consistency
* Major re-work of type printer support to take full control of the mapping to managed code
- Bypassed all the default conversion to CIL types that CppSharp would do during a parse so that only the real native types are in place and ToString() shows the underlying source type.
* Code analysis cleanup
* Bumped default range of VS to include VS2022 if available
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.
Refactoring LlvmBindingsGenerator
A Major goal of this work is to remove the confusion from CppSharp's automatic morphing of types and to get around it's weird AST.Type.ToString() implementation that has no default implementation to show the source language type. Additionally this is intended to help in splitting the code generator portions from the actual "driver" application so that research into use with Roslyn SourceGeneratos is a viable option. (See #214 for additional info) Even with code gen for the interop there still needs to be support to generate the EXPORTS.DEF for the native code, so there is likely a need for an intermediate "database" that can store the relevant data from the parse tree that is then useable for code generation. (e.g., Generation doesn't actually need the FULL parse tree, just a fairly small subset of the information is needed to generate the interop code)