dblaikie added a comment.
In D70524#1779179 <https://reviews.llvm.org/D70524#1779179>, @awpandey wrote:
> @dblaikie . I have removed the redundant test case. What else should I do in
> this patch?
Please address this warning before committing:
/usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:3100:3:
warning: unannotated fall-through between switch labels
[-Wimplicit-fallthrough]
case Type::Attributed:
^
/usr/local/google/home/blaikie/dev/llvm/src/clang/lib/CodeGen/CGDebugInfo.cpp:3100:3:
note: insert 'break;' to avoid fall-through
case Type::Attributed:
^
break;
1 warning generated.
It looks like this implementation is a bit buggy in one way and incomplete in
another:
1. even if the auto-returning function is defined, that function definition
doesn't describe the concrete return type. Compare GCC and Clang's output for
your example and note that... oh.
Hmm, maybe this feature/suggestion is broken or at least not exactly awesome
when it comes to auto-returning functions that are eventually void-returning
functions? Now the function definition has no DW_AT_type to override the
unspecified_type in the declaration... :/ that's unfortunate (@probinson -
thoughts?) GCC does use the unspecified type "auto" even back in DWARFv4 and it
leaves the subprogram definition DIE without a DW_AT_type if the auto type ends
up as void (what else could it do?) so I guess we can do this for consistency &
consumers have to know that a definition can't really have an auto return type
and that it must be really void.
In any case - change the test case to use a non-void return type in the
definition ("return 3;" for instance, to get an int return type instead) and
check that the DISubprogram for the definition has a concrete return type of
"int" while the DISubprogram for the declaration has the "auto"
unspecified_type return type. (contrast/test against GCC's behavior)
2. Presumably in a follow-up patch, make sure that the declaration for the
DISubprogram declaration for an "auto" return type function appears in the
member list of the DICompositeType even if the function is not called (same as
other normal (non-implicit/non-template) functions) since that's the value of
being able to describe the return type as "auto" (the function can be described
even when the definition isn't available/emitted) - it doesn't currently.
(contrast/test against with GCC's behavior)
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
