-
Notifications
You must be signed in to change notification settings - Fork 513
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
Typemap cleanup #1802
Typemap cleanup #1802
Changes from 11 commits
6268b1c
8271415
e667b2c
473ecf9
5cb553a
c1f392f
bf5a6ea
15ecf3b
64c3b24
502d77e
fdf796d
d44b31c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -63,12 +63,9 @@ public static Type GetMappedType(this Type type, TypeMapDatabase typeMaps, | |
Type = typeMap.Type | ||
}; | ||
|
||
switch (generatorKind) | ||
if (generatorKind == GeneratorKind.CLI || generatorKind == GeneratorKind.CSharp) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can we remove this if now? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To be honest, I am not totally sure, I can try removing it and run the tests and see what goes on. Here I am refactoring while keeping the same semantics. |
||
{ | ||
case var _ when ReferenceEquals(generatorKind, GeneratorKind.CLI): | ||
return typeMap.CLISignatureType(typePrinterContext).Desugar(); | ||
case var _ when ReferenceEquals(generatorKind, GeneratorKind.CSharp): | ||
return typeMap.CSharpSignatureType(typePrinterContext).Desugar(); | ||
return typeMap.SignatureType(typePrinterContext).Desugar(); | ||
} | ||
} | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here we explicitly specify
GeneratorKind.CSharp
becauseCSharpTypePrinter
is used in CLI. Many similar cases are found in this file,src/Generator/Passes/ExpressionHelper.cs
andsrc/Generator/Passes/ValidateOperatorsPass.cs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I totally understand why, why is it a problem to pass GeneratorKind.CLI in these cases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After a bit of analysis and tests I found out that the CLI backend depends on CSharp typemaps in some ways.
Consider the
DelegatesPass
which is common for CLI and CSharp, it usesCSharpTypePrinter
which itself uses theCSharp
typemaps. Not passing theGeneratorKind.CSharp
explicitly will make theDelegatesPass
uses CLI typemaps, which is not desirable in this case.Consider the Employee.h example:
Using CLI typemap (undesired):
// Employee.h CLI generated header [::System::Runtime::InteropServices::UnmanagedFunctionPointer(::System::Runtime::InteropServices::CallingConvention::Cdecl)] delegate ::System::String^ Func__System_String^ ___IntPtr(::System::IntPtr __instance);
Using C# typemaps (desired):
// Employee.h CLI generated header [::System::Runtime::InteropServices::UnmanagedFunctionPointer(::System::Runtime::InteropServices::CallingConvention::Cdecl)] delegate ::System::String^ Func_std_basic_string___Internalc__N_std_S_basic_string__C___N_std_S_char_traits__C___N_std_S_allocator__C___IntPtr(::System::IntPtr __instance);
Apparently this signature must match the
CSharp
one (in the generated .cs file) in order for the project to compile.To he honest, I was a bit confused why such mess is going on, but then I focused on refactoring rather than changing semantics.
This is why I am working on refactoring the project into modular design because with its current status it is nearly impossible to afford more generators with new semantics/heuristics. Isolating generators is a big win for future development, allowing reusable components as the current status which is also good (but we should add remarks/best practices).
Maybe someone with deeper knowledge on how the
CSharp/CLI
backend is operating can help us too. I can invest some time into these backends and see how they can be improved (and you should know that there is a lot of room for improvements), but I am thinking of sparing my efforts for newer generators.By the way, I was thinking if we can standardize/document the typemap concept in details because it is a major concept in binding generation and currently I am finding it a bit confusing when comparing its usage across different generators. Maybe a kind of README/pseudocode can help a lot for users/collaborators.