For bug 427536, I need struct lang_type from cp-tree.h exposed to Treehydra. (We need this data to tell the different between a struct and a class.) This is a union type. We also kind of need it for pretty-printing pointer-to-member types, but that's less important.
Created attachment 314227 [details] [diff] [review] I hate unions and ad-hoc ways to describe them This should work.
Thanks. That works. Unfortunately, there is more where that came from (as I just discovered after reenabling the union-y code). Dehydra uses DECL_CLONED_FUNCTION_P, which ultimately requires this line of code to work in Treehydra: DECL_LANG_SPECIFIC(node).u.f.u5.cloned_function; This refers to struct lang_decl in cp-tree.h, going through union field u, then struct field f, then union field u5.
Just another quick note, the DECL_LANG_SPECIFIC/lang_decl union stuff also seems to be required in order to do anything much with templates.
This is going to take a pretty serious switcheroo in convert_tree.js and the generated files. I'm posting a plan of attack for own notes here: 1) Make convert_* functions work like dehydra_defineProperty such that they return void This also helps avoid rooting for location_t conversion 2) Implement correct support for %1 and %0 gengtype crap. This means that structs and unions defined within other structs will no longer get a toplevel func, instead they will get "inlined" into the conversion func for the toplevel struct 3) Enable all nested tagged unions, later might enable remaining toplevel ones.
I've done 1) so far, the rest should be finished by end of the week. This bug blocks further Treehydra changes since rearranges the code a fair bit.
Summary: Treehydra: Expose struct lang_type → Treehydra: Expose struct lang_type. Support anonymous tagged unions automatically
Created attachment 317644 [details] [diff] [review] lang_type for dmandelin the convert_tree.js code makes sense, but i can't decypher how node.type.lang_specific.u.h is supposed to work in C given that there is no h in lang_decl_u4 Any ideas? I'm done with this for today
Assignee: nobody → tglek
Attachment #314227 - Attachment is obsolete: true
figured it out, turned i didn't infer enough about GCC tagged unions. In a tagged union if there is no tag on a field, means it's always present. GCC also marked the .h part was being a "skip", evil thing.
Committed fix + testcase
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.