Various fixes from stylo #9
Open
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
The correct thing to do here is to use env_logger, but that was causing cargo troubles for me, and this is preferable to swallowing them.
It looks like mwu added this, but I'm pretty sure it's a category error. This function appears to be designed to reproducibly permute C identifiers so that they don't conflict with builtin rust types. It's specifically _not_ a type translator (which would happen at the type level, rather than the string level), and using it as such with callers like ctypedef_to_rs causes us to generate things like: type u64 = u64; While processing stdint.h, which is clearly wrong.
…s during code generator.
As best as I can tell, it's done this way (rather than my way) because bindgen tries
to recognize struct and enums typedefs of the form:
/* This is a common idiom in C, not so much in C++ */
typdef struct {
...
} Foo;
The intention, I think, is to avoid generating rust code for a struct with a placeholder
name followed by a typedef, and just give the struct the right name initially.
This seems like a reasonable goal, though not a particularly important one. However, in
my testing this never actually happens, because we end up calling unnamed_name anyway
during the GComp(ci) case of gen_mod before we get to evaluting the typedef.
So let's just remove that stuff and simplify the code. This lets us remove all the
borrow_mut calls during code generation, which seems necessary for soundness.
gen: Allow empty union bitfield members
We currently generate the modules as expected, but we don't resolve the names from external namespaces well.
Overall now that they aren't complete still.
Basic C++ namespace support
This way we can share the global map, while having each module custom globals.
This actually keeps working as before.
We generate almost valid code, we just have to add some use statements. Or maybe is a better idea to add an unintelligible name to the root mod, and actually output a root mod plus a use root::* before.
There's just an edge case I've detected, and it's when we remove the instantiation of C<int>, and another module uses it, because that means we only know of its existance in that other module. Probably we might want to use cursor_getSemanticParent to get the real class instead of the instantiated, but I'm not too confident about that.
This can be annoying if filtering files out.
C++ namespaces \o/
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.
No description provided.