<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 8, 2014 at 10:31 AM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">This means you will see "S<A>" as the type for your variables in the debugger when you view variables or children of structs/unions/classes. I think this is not what the user would want to see. I would rather see "S<int>" as the type for my variable than see "S<A>".<br></blockquote><div><br></div><div>Clang generally hasn't taken this direction (granted, using the debugger might have different priorities from using the compiler)<br><br><pre style="color:rgb(0,0,0)">type.cpp:5:6: note: candidate function not viable: no known conversion from 'foo<bar>' to 'int' for 1st argument
void func(int) {
^
(for example, where 'bar' is 'typedef int bar')</pre></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div><div class="h5"><br>
> On Sep 5, 2014, at 4:00 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br>
><br>
><br>
>> On Sep 5, 2014, at 3:49 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>><br>
>> On Fri, Sep 5, 2014 at 3:43 PM, Duncan P. N. Exon Smith <<a href="mailto:dexonsmith@apple.com">dexonsmith@apple.com</a>> wrote:<br>
>><br>
>> > On 2014 Sep 5, at 16:01, Frédéric Riss <<a href="mailto:friss@apple.com">friss@apple.com</a>> wrote:<br>
>> ><br>
>> > I couldn’t even find a subject expressing exactly what this patch is about… First of all, it’s meant to start a discussion, and I’m not proposing it for inclusion right now.<br>
>> ><br>
>> > The issue I’m trying to address is that template types are always canonicalized when emitted in the debug information (this is the desugar() call in UnwrapTypeForDebugInformation).<br>
>> ><br>
>> > This means that if the developer writes:<br>
>> ><br>
>> > typedef int A;<br>
>> > template <typename T><br>
>> > struct S {};<br>
>> ><br>
>> > S<A> var;<br>
>> ><br>
>> > The variable var will have type S<int> and not S<A>. In this simple example, it’s not that much of an issue, but for heavily templated code, the full expansion might be really different from the original declaration.<br>
>> ><br>
>> > The attached patch makes us emit an intermediate typedef for the variable’s type:<br>
>> ><br>
>> > 0x0000002a: DW_TAG_variable [2]<br>
>> > DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000032] = “var")<br>
>> > DW_AT_type [DW_FORM_ref4] (cu + 0x0040 => {0x00000040})<br>
>> > DW_AT_external [DW_FORM_flag] (0x01)<br>
>> > DW_AT_decl_file [DW_FORM_data1] (0x01)<br>
>> > DW_AT_decl_line [DW_FORM_data1] (8)<br>
>> > DW_AT_location [DW_FORM_block1] (<0x09> 03 70 6c 00 00 00 00 00 00 )<br>
>> ><br>
>> > 0x00000040: DW_TAG_typedef [3]<br>
>> > DW_AT_type [DW_FORM_ref4] (cu + 0x004b => {0x0000004b})<br>
>> > DW_AT_name [DW_FORM_strp] ( .debug_str[0x00000035] = “S<A>")<br>
>> > DW_AT_decl_file [DW_FORM_data1] (0x01)<br>
>> > DW_AT_decl_line [DW_FORM_data1] (6)<br>
>> ><br>
>> > 0x0000004b: DW_TAG_structure_type [4] *<br>
>> > DW_AT_name [DW_FORM_strp] ( .debug_str[0x0000003e] = “S<int>")<br>
>> > DW_AT_byte_size [DW_FORM_data1] (0x01)<br>
>> > DW_AT_decl_file [DW_FORM_data1] (0x01)<br>
>> > DW_AT_decl_line [DW_FORM_data1] (6)<br>
>> ><br>
>> ><br>
>> > Which basically is what I want, although I don’t like that it introduces a typedef where there is none in the code. I’d prefer that to be:<br>
>> ><br>
>> > DW_TAG_variable<br>
>> > DW_AT_type: -> DW_TAG_structure_type<br>
>> > DW_AT_name: S<A><br>
>> > DW_AT_specification: -> DW_TAG_structure_type<br>
>> > DW_AT_name: S<int><br>
>> > …<br>
>> ><br>
>> > The patch also has the nice property of omitting the defaulted template arguments in the first level typedef. For example you get vector<A> instead of vector<int, std::__1::allocator<int> >.<br>
>><br>
>> If you specify `vector<int>` in C++ do you get that instead of<br>
>> `vector<int, std::__1::allocator<int>>`?<br>
>><br>
>> Yeah, I mentioned this as possibly causing problems with debuggers or other consumers, but I don't have any proof past "ooooo scary!”.<br>
><br>
> Well, [+lldb-dev], could this confuse debuggers? :-)<br>
><br>
> -- adrian<br>
>><br>
>> That said, I like the idea personally :)<br>
>><br>
>> -eric<br>
>><br>
>><br>
>> > Now there is one thing I really don’t like about the patch. In order not to emit typedefs for types that don’t need it, I use string comparison between the desugared and the original type. I haven’t quantified anything, but doing the construction of the type name for every template type and then comparing it to decide to use it or not seems like a big waste.<br>
>><br>
>> Maybe someone on cfe-dev knows a better way.<br>
>><br>
>> ><br>
>> > Thoughts?<br>
>> ><br>
>> > <template-arg-typedefs.diff><br>
>> ><br>
>> > Fred<br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > llvm-commits mailing list<br>
>> > <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
>> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
>><br>
>><br>
><br>
</div></div>> _______________________________________________<br>
> lldb-dev mailing list<br>
> <a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br>
</blockquote></div><br></div></div>