Cleanup how the PInvokeGenerator handles CXType and resolves names #61
Conversation
…ing for multi-file
|
This also sets things up so that support for generating "safe code" can be removed. This support, while nice, is very error prone and can have various hidden overhead that isn't going to be easy to maintain long term. Namely, things like The best case scenario is to just generate bindings which have 1-to-1 mapping with the underlying signatures and with no marshaling. This gives a zero-cost (modulo the overhead of the P/Invoke stub) abstraction over the native APIs which allows usage in performance oriented scenarios and allows better use with new library functionality such as |
| } | ||
| return name; | ||
| } | ||
| case "size_t": |
There was a problem hiding this comment.
size_t is spec'd to be unsigned, so this is a change in how the bindings are generated.
| { | ||
| switch (decl.Kind) | ||
| case "int64_t": | ||
| case "time_t": |
There was a problem hiding this comment.
time_t is generally 64-bit on modern hardware (even 32-bit machines), but not always. Should probably provide a way to override this....
This does some minor cleanup that namely extends the CXType wrapper to more closely match the Clang C++ bindings.
This also improves how cursor and type names are resolved to better match how the wrapper types/etc are generated.