On Mon, Sep 8, 2014 at 10:31 AM, Greg Clayton <gclay...@apple.com> wrote:
> 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>".
>
Clang generally hasn't taken this direction (granted, using the debugger
might have different priorities from using the compiler)
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')
>
> > On Sep 5, 2014, at 4:00 PM, Adrian Prantl <apra...@apple.com> wrote:
> >
> >
> >> On Sep 5, 2014, at 3:49 PM, Eric Christopher <echri...@gmail.com>
> wrote:
> >>
> >>
> >>
> >>
> >> On Fri, Sep 5, 2014 at 3:43 PM, Duncan P. N. Exon Smith <
> dexonsm...@apple.com> wrote:
> >>
> >> > On 2014 Sep 5, at 16:01, Frédéric Riss <fr...@apple.com> wrote:
> >> >
> >> > 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.
> >> >
> >> > 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).
> >> >
> >> > This means that if the developer writes:
> >> >
> >> > typedef int A;
> >> > template <typename T>
> >> > struct S {};
> >> >
> >> > S<A> var;
> >> >
> >> > 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.
> >> >
> >> > The attached patch makes us emit an intermediate typedef for the
> variable’s type:
> >> >
> >> > 0x0000002a: DW_TAG_variable [2]
> >> > DW_AT_name [DW_FORM_strp] (
> .debug_str[0x00000032] = “var")
> >> > DW_AT_type [DW_FORM_ref4] (cu + 0x0040 =>
> {0x00000040})
> >> > DW_AT_external [DW_FORM_flag] (0x01)
> >> > DW_AT_decl_file [DW_FORM_data1] (0x01)
> >> > DW_AT_decl_line [DW_FORM_data1] (8)
> >> > DW_AT_location [DW_FORM_block1] (<0x09> 03 70 6c 00 00
> 00 00 00 00 )
> >> >
> >> > 0x00000040: DW_TAG_typedef [3]
> >> > DW_AT_type [DW_FORM_ref4] (cu + 0x004b =>
> {0x0000004b})
> >> > DW_AT_name [DW_FORM_strp] (
> .debug_str[0x00000035] = “S<A>")
> >> > DW_AT_decl_file [DW_FORM_data1] (0x01)
> >> > DW_AT_decl_line [DW_FORM_data1] (6)
> >> >
> >> > 0x0000004b: DW_TAG_structure_type [4] *
> >> > DW_AT_name [DW_FORM_strp] (
> .debug_str[0x0000003e] = “S<int>")
> >> > DW_AT_byte_size [DW_FORM_data1] (0x01)
> >> > DW_AT_decl_file [DW_FORM_data1] (0x01)
> >> > DW_AT_decl_line [DW_FORM_data1] (6)
> >> >
> >> >
> >> > 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:
> >> >
> >> > DW_TAG_variable
> >> > DW_AT_type: -> DW_TAG_structure_type
> >> > DW_AT_name: S<A>
> >> > DW_AT_specification: -> DW_TAG_structure_type
> >> > DW_AT_name: S<int>
> >> > …
> >> >
> >> > 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> >.
> >>
> >> If you specify `vector<int>` in C++ do you get that instead of
> >> `vector<int, std::__1::allocator<int>>`?
> >>
> >> Yeah, I mentioned this as possibly causing problems with debuggers or
> other consumers, but I don't have any proof past "ooooo scary!”.
> >
> > Well, [+lldb-dev], could this confuse debuggers? :-)
> >
> > -- adrian
> >>
> >> That said, I like the idea personally :)
> >>
> >> -eric
> >>
> >>
> >> > 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.
> >>
> >> Maybe someone on cfe-dev knows a better way.
> >>
> >> >
> >> > Thoughts?
> >> >
> >> > <template-arg-typedefs.diff>
> >> >
> >> > Fred
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > llvm-commits mailing list
> >> > llvm-comm...@cs.uiuc.edu
> >> > http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
> >>
> >>
> >
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev@cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
>
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
