Issue with displaying a union of templated type in debugger

I’m not sure if this has been reported, but I have come across an issue with trying to view data that is within a union Xcode’s debug view, specifically when the data type is templated. Please consider the following:

template
struct vec2 {
union { T x, r; };
union { T y, g; };
};

int main()
{
vec2 foo = { 2.0f, 3.0f };
return 0;
}

If I place a breakpoint on the return statement and exam foo, I see two tabs with no name. Clicking on either tab shows an array of ‘y = 3, g = 3’, while there is no sign of x (or r). Something is going wrong here.

However if I remote the templating:

struct vec2 {
union { float x, r; };
union { float y, g; };
};

int main()
{
vec2 foo = { 2.0f, 3.0f };
return 0;
}

and example the data in the same manner, I see that one tab has an array of ‘x = 2, r = 2’, and the other is ‘y = 3, g = 3’. Is this a known issue? I discovered this while trying to make use of the popular glm math library (http://glm.g-truc.net/), which uses unions in this manner to follow the GLSL types spec.

As an aside, I think the display of unions in general (even without the templates) is not ideal, at first glance it is difficult to make out what the data is at all, given that it is a) hidden underneath tabs with no names and b) duplicated. Has there been any thought towards how to better represent this data in the debugger?

Thanks,
Rich

This sort of bug tends to be either a debug information problem or the debugger misinterpreting it somehow. If the y & g fields were present, but with the wrong values, is is more likely the latter cause, if they are just missing, it is more likely the former. That being said this problem doesn't reproduce in TOT lldb using a pretty recent clang-600 branch compiler. The lldb equivalent of the Xcode locals view is what gets printed out with the "frame variable" command, and your example shows:

(lldb) frame var foo
(vec2<float>) foo = {
   = {
    x = 2
    r = 2
  }
   = {
    y = 3
    g = 3
  }
}

which is right. What version of clang are you using when you see this?

Jim