Community
Participate
Working Groups
Nested designated initializers are not getting resolved. Here is an example: #include <stdio.h> typedef struct { int x; int y; } Point ; typedef struct { Point p1; Point p2; } Line ; int main() { Point p1 = {.x = 1, .y = 2}; // works fine // x and y not resolved Line l1 = {{.x = 1, .y = 2}, {.x = 3, .y = 4}}; // x and y not resolved Line l2 = {.p1.x = 1, .p1.y = 2, .p2.x = 3, .p2.y = 4}; } This looks very tricky because the position of the nested initializer within the outer initializer is significant. I'm trying to get this to work with the new C99 parser and I noticed it doesn't work with the DOM C parser either.
Wow, good catch Mike. I didn't even know about this feature. I saw some code like it but I thought the guy was just writing pseudo code. You learn something every day...
(In reply to comment #1) And it looks like it would be pretty hard to implement. Here's an article with some crazy examples (about half way down): http://www.ddj.com/cpp/184401377
Added test cases: Failing: AST2Tests._testBug210019_nestedDesignatedInitializers() This one passes: AST2Tests.testBug210019_designatedInitializers()
*** Bug 530289 has been marked as a duplicate of this bug. ***
This is still an issue. In C code, CDT does not produce semantic errors for nested initializers, but they do not get syntax coloring, either. In C++ code (where GCC supports designated initializers as an extension, and CDT attempts to as well since bug 406462), CDT produces semantic errors for the nested initializers.
Any progress on this issue?
(In reply to Jiri Engelthaler from comment #6) > Any progress on this issue? Nope. Given how behind we are on standard C++ support, non-standard extensions like this are a low priority. If this particular extension is important to you, patches are welcome. I'm happy to help by reviewing.
