[Bug 20609] New: Issue with displaying a union of templated type in debugger

Bug ID 20609
Summary Issue with displaying a union of templated type in debugger
Product lldb
Version 3.4
Hardware Macintosh
Status NEW
Severity normal
Priority P
Component All Bugs
Assignee lldb-dev@cs.uiuc.edu
Reporter rtepub@gmail.com
Classification Unclassified

(I tried to post this to the lldb-dev list a few days ago but it was blocked by
moderator. Not sure why, so I'm submitting as a bug, aplogies if it is a

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 <typename T>
struct vec2 {
    union { T x, r; };
    union { T y, g; };

int main()
  vec2<float> 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, 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?


other version info:
Xcode: 5.1.1 (5B1008)
clang: Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
lldb: lldb-310.2.37

Jim Ingham changed bug 20609

What Removed Added
CC jingham@apple.com
Resolution FIXED

Comment # 1 on bug 20609 from Jim Ingham

I cannot reproduce this issue with

Apple LLVM version 6.0 (clang-600.0.47) (based on LLVM 3.5svn)

and the current TOT lldb.  This is most likely not an lldb bug at all, but a
clang bug.

But anyway, it looks like it is fixed in more recent tools.