dblaikie added a comment.
In D70524#1761514 <https://reviews.llvm.org/D70524#1761514>, @awpandey wrote:
> Hi @aprantl and @dblaikie. Currently, there is no test case for the
> unspecified type, so I have added that in the regression test suite.
It looks to me like there are a few tests for unspecified_type already:
$ grep -r unspecified_type llvm/test
llvm/test/Assembler/debug-info.ll:; CHECK-NEXT: !7 = !DIBasicType(tag:
DW_TAG_unspecified_type, name: "decltype(nullptr)")
llvm/test/Assembler/debug-info.ll:!8 = !DIBasicType(tag:
DW_TAG_unspecified_type, name: "decltype(nullptr)")
llvm/test/DebugInfo/COFF/types-std-nullptr-t.ll:!6 = !DIBasicType(tag:
DW_TAG_unspecified_type, name: "decltype(nullptr)")
llvm/test/DebugInfo/X86/template.ll:; VERIFY-NOT: error: DIE has DW_AT_type
with incompatible tag DW_TAG_unspecified_type
llvm/test/DebugInfo/X86/template.ll:; CHECK: [[NULLPTR]]:{{
*}}DW_TAG_unspecified_type
llvm/test/DebugInfo/X86/template.ll:!34 = !DIBasicType(tag:
DW_TAG_unspecified_type, name: "decltype(nullptr)")
@aprantl @probinson - I'm going to voice a little more objection to this
feature as I think I did when it was being discussed for DWARF standardization
- feel free to push back/veto me/etc: Describing this seems of limited value to
consumers - the function cannot be called if the return type hasn't been
resolved. I think modeling these sort of situations the same way member
function templates are would be fine - omit the declaration entirely in
translation units that have no function definition for an auto-returning
function.
The only difference between this and templates is that we /can/ describe it &
it can be useful for overload resolution - but the same is true of all
functions (non-member, member, etc) & no DWARF producer I know of produces all
function declarations into their output, so I'm not sure "make overload
resolution work" is really a worthwhile goal. (without template descripttions
(not the instantiations, but the templates themselves which we currently have
no way of describing even if we wanted to) I don't think it's actually
achievable)
================
Comment at: clang/test/CodeGenCXX/debug-info-auto-return.cpp:12-15
+class myClass {
+ int low, high;
+
+public:
----------------
I'd probably make this a struct, rather than a class with a public member -
access modifiers aren't relevant to this test, so far as I can tell, so might
as well just have everything public by using a struct.
================
Comment at: clang/test/CodeGenCXX/debug-info-auto-return.cpp:13
+class myClass {
+ int low, high;
+
----------------
No need for any member variables, I think?
================
Comment at: clang/test/CodeGenCXX/debug-info-auto-return.cpp:20-23
+ if (low > high)
+ return 1;
+ else
+ return 1;
----------------
Could strip out the body here - leave a single "return 0;" in there if that's
useful/needed.
================
Comment at: llvm/test/DebugInfo/X86/debug-info-auto-return.ll:5-25
+;class myClass {
+; int low, high;
+;
+; public:
+; myClass(int a, int b) {
+; low = a;
+; high = b;
----------------
This code seems more complicated than it needs to be (it doesn't need any logic
in the body of the functions, for instance, I think? Nor any member variables,
nor 'main', etc) & the indentation should be fixed/made consistent.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D70524/new/
https://reviews.llvm.org/D70524
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
