[clang] [llvm] Add support for template as type parameter (PR #127654)

[via cfe-commits]

ykhatav wrote:

> > For template classes with type parameters, the information of which member variables are of a "templated type" is lost. The debugger cannot differentiate between "templated" types and "hardcoded" types. This is because both types have the same debug information, so there is no way that gdb can distinguish between them. This patch adds support for templates as type by representing the template type as a derived type.
> 
> What features are you hoping to build on this debug info?

I would say it is more of an improvement in debug information. The current implementation of Clang generates DWARF debug information that could be improved for better compliance with DWARF v5 standards. Consider the example D.11 from DWARF v5. Currently, Clang produces the following DWARF output:
```
0x0000003e:   DW_TAG_base_type
                DW_AT_name      ("int")
                DW_AT_encoding  (DW_ATE_signed)
                DW_AT_byte_size (0x04)

0x00000042:   DW_TAG_structure_type
                DW_AT_calling_convention        (DW_CC_pass_by_value)
                DW_AT_name      ("wrapper<int>")
                DW_AT_byte_size (0x04)
                DW_AT_decl_file ("")
                DW_AT_decl_line (2)

0x00000048:     DW_TAG_template_type_parameter
                  DW_AT_type    (0x0000003e "int")
                  DW_AT_name    ("T")

0x0000004e:     DW_TAG_member
                  DW_AT_name    ("comp")
                  DW_AT_type    (0x0000003e "int")
                  DW_AT_decl_file       ("")
                  DW_AT_decl_line       (3)
                  DW_AT_data_member_location    (0x00)
```


Note that the type of variable "comp" directly references "int" instead of DW_TAG_template_type_parameter. 
> Mostly I worry it won't be terribly complete, because it can't work through situations, like this:
> 
> ```
> template<typename T>
> struct trait {
>   using type = T;
> };
> template<typename T>
> struct other {
>   trait<T>::type v1;
>   T v2;
> };
> ```
> 
> In this case, v2 can be described as being of type "T" referencing the template_type_parameter, but v1 can't be - because it references trait::type, for instance.

I believe, in this case, the debug information of "v2" can still be improved and align with DWARF v5, it could be represented using DW_TAG_template_type instead of "int":

```
0x00000042:   DW_TAG_structure_type
                DW_AT_calling_convention        (DW_CC_pass_by_value)
                DW_AT_name      ("other<int>")
                DW_AT_byte_size (0x08)
                DW_AT_decl_file ("")
                DW_AT_decl_line (6)

0x00000048:     DW_TAG_template_type_parameter
                  DW_AT_type    (0x0000003e "int")
                  DW_AT_name    ("T")

0x0000004e:     DW_TAG_member
                  DW_AT_name    ("v1")
                  DW_AT_type    (0x0000006d "trait<int>::type")
                  DW_AT_decl_file       ("")
                  DW_AT_decl_line       (7)
                  DW_AT_data_member_location    (0x00)

0x00000057:     DW_TAG_member
                  DW_AT_name    ("v2")
                  DW_AT_type    (0x00000048 "other<int>::T")
                  DW_AT_decl_file       ("")
                  DW_AT_decl_line       (8)
                  DW_AT_data_member_location    (0x04)
```


> Also, I'd worry that most debuggers/DWARF consumers aren't ready to handle type references to template_type_parameters? So best to test this with at least LLDB and GDB before we commit it.

While I acknowledge that current debuggers may not fully support this DWARF representation, I suggest that this implementation be controlled by a switch until downstream tools are updated to accommodate these changes.


https://github.com/llvm/llvm-project/pull/127654