2015-10-08 12:24:12 +08:00
|
|
|
// RUN: %clang_cc1 -triple %itanium_abi_triple -emit-llvm-only -std=c++14 -emit-llvm -debug-info-kind=limited %s -o - | FileCheck %s
|
PR16091 continued: Debug Info for member functions with undeduced return types.
So DWARF5 specs out auto deduced return types as DW_TAG_unspecified_type
with DW_AT_name "auto", and GCC implements this somewhat, but it
presents a few problems to do this with Clang.
GCC's implementation only applies to member functions where the auto
return type isn't deduced immediately (ie: member functions of templates
or member functions defined out of line). In the common case of an
inline deduced return type function, GCC emits the DW_AT_type as the
deduced return type.
Currently GDB doesn't seem to behave too well with this debug info - it
treats the return type as 'void', even though the definition of the
function has the correctly deduced return type (I guess it sees the
return type the declaration has, doesn't understand it, and assumes
void). This means the function's ABI might be broken (non-trivial return
types, etc), etc.
Clang, on the other hand doesn't track this particular case of a
deducable return type that is deduced immediately versus one that is
deduced 'later'. So if we implement the DWARF5 representation, all
deducible return type functions would get adverse GDB behavior
(including deduced return type lambda functions, inline deduced return
type functions, etc).
Also, we can't just do this for auto types that are not deduced -
because Clang marks even the declaration's return type as deduced (&
provides the underlying type) once a definition is seen that allows the
deduction. So we have to ignore even deduced types - but we can't do
that for auto variables (because this representation only applies to
function declarations - variables and function definitions need the real
type so the function can be called, etc) so we'd need to add an extra
flag to the type unwrapping/creation code to indicate when we want to
see through deduced types and when we don't. It's also not as simple as
just checking at the top level when building a function type (for one
thing, we reuse the function type building for building function pointer
types which might also have 'auto' in them - but be the type of a
variable instead) because the auto might be arbitrarily deeply nested
("auto &", "auto (*)()", etc...)
So, with all that said, let's do the simple thing that works in existing
debuggers for now and treat these functions the same way we do function
templates and implicit special members: omit them from the member list,
since they can't be correctly called anyway (without knowing the return
type the ABI isn't know and a function call could put the arguments in
the wrong place) so they're not much use to the user.
At some point in the future, when GDB understands the DWARF5
representation better it might be worth plumbing through the extra type
builder handling to avoid looking through AutoType for some callers,
etc...
llvm-svn: 221704
2014-11-12 04:44:45 +08:00
|
|
|
|
2016-08-06 03:03:01 +08:00
|
|
|
// CHECK: imports: [[IMPS:![0-9]*]]
|
2014-12-16 03:10:08 +08:00
|
|
|
// CHECK: [[EMPTY:![0-9]*]] = !{}
|
2016-08-06 03:03:01 +08:00
|
|
|
|
|
|
|
|
// CHECK: [[IMPS]] = !{[[IMP:![0-9]*]]}
|
|
|
|
|
// CHECK: [[IMP]] = !DIImportedEntity(
|
|
|
|
|
// CHECK-SAME: entity: [[F3:![0-9]*]]
|
|
|
|
|
// CHECK: [[F3]] = distinct !DISubprogram(name: "f3"
|
2015-03-04 01:25:55 +08:00
|
|
|
// CHECK-SAME: type: [[SUBROUTINE_TYPE:![0-9]*]]
|
2015-04-30 00:40:08 +08:00
|
|
|
// CHECK: [[SUBROUTINE_TYPE]] = !DISubroutineType(types: [[TYPE_LIST:![0-9]*]])
|
2014-12-16 03:10:08 +08:00
|
|
|
// CHECK: [[TYPE_LIST]] = !{[[INT:![0-9]*]]}
|
2015-04-30 00:40:08 +08:00
|
|
|
// CHECK: [[INT]] = !DIBasicType(name: "int"
|
2016-08-06 03:03:01 +08:00
|
|
|
|
2016-09-13 09:13:19 +08:00
|
|
|
// CHECK: [[FOO:![0-9]+]] = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "foo",
|
|
|
|
|
// CHECK-SAME: elements: [[EMPTY]]
|
|
|
|
|
|
2016-08-06 03:03:01 +08:00
|
|
|
// FIXME: The context of this definition should be the CU/file scope, not the class.
|
|
|
|
|
// CHECK: !DISubprogram(name: "func", {{.*}} scope: [[FOO]]
|
|
|
|
|
// CHECK-SAME: type: [[SUBROUTINE_TYPE]]
|
|
|
|
|
// CHECK-SAME: isDefinition: true
|
|
|
|
|
// CHECK-SAME: declaration: [[FUNC_DECL:![0-9]*]]
|
2015-04-30 00:40:08 +08:00
|
|
|
// CHECK: [[FUNC_DECL]] = !DISubprogram(name: "func",
|
2016-04-24 05:08:27 +08:00
|
|
|
// CHECK-SAME: scope: [[FOO]]
|
2015-03-04 01:25:55 +08:00
|
|
|
// CHECK-SAME: type: [[SUBROUTINE_TYPE]]
|
|
|
|
|
// CHECK-SAME: isDefinition: false
|
2013-05-25 05:24:35 +08:00
|
|
|
|
|
|
|
|
struct foo {
|
PR16091 continued: Debug Info for member functions with undeduced return types.
So DWARF5 specs out auto deduced return types as DW_TAG_unspecified_type
with DW_AT_name "auto", and GCC implements this somewhat, but it
presents a few problems to do this with Clang.
GCC's implementation only applies to member functions where the auto
return type isn't deduced immediately (ie: member functions of templates
or member functions defined out of line). In the common case of an
inline deduced return type function, GCC emits the DW_AT_type as the
deduced return type.
Currently GDB doesn't seem to behave too well with this debug info - it
treats the return type as 'void', even though the definition of the
function has the correctly deduced return type (I guess it sees the
return type the declaration has, doesn't understand it, and assumes
void). This means the function's ABI might be broken (non-trivial return
types, etc), etc.
Clang, on the other hand doesn't track this particular case of a
deducable return type that is deduced immediately versus one that is
deduced 'later'. So if we implement the DWARF5 representation, all
deducible return type functions would get adverse GDB behavior
(including deduced return type lambda functions, inline deduced return
type functions, etc).
Also, we can't just do this for auto types that are not deduced -
because Clang marks even the declaration's return type as deduced (&
provides the underlying type) once a definition is seen that allows the
deduction. So we have to ignore even deduced types - but we can't do
that for auto variables (because this representation only applies to
function declarations - variables and function definitions need the real
type so the function can be called, etc) so we'd need to add an extra
flag to the type unwrapping/creation code to indicate when we want to
see through deduced types and when we don't. It's also not as simple as
just checking at the top level when building a function type (for one
thing, we reuse the function type building for building function pointer
types which might also have 'auto' in them - but be the type of a
variable instead) because the auto might be arbitrarily deeply nested
("auto &", "auto (*)()", etc...)
So, with all that said, let's do the simple thing that works in existing
debuggers for now and treat these functions the same way we do function
templates and implicit special members: omit them from the member list,
since they can't be correctly called anyway (without knowing the return
type the ABI isn't know and a function call could put the arguments in
the wrong place) so they're not much use to the user.
At some point in the future, when GDB understands the DWARF5
representation better it might be worth plumbing through the extra type
builder handling to avoid looking through AutoType for some callers,
etc...
llvm-svn: 221704
2014-11-12 04:44:45 +08:00
|
|
|
static auto func();
|
2013-05-25 05:24:35 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
foo f;
|
PR16091 continued: Debug Info for member functions with undeduced return types.
So DWARF5 specs out auto deduced return types as DW_TAG_unspecified_type
with DW_AT_name "auto", and GCC implements this somewhat, but it
presents a few problems to do this with Clang.
GCC's implementation only applies to member functions where the auto
return type isn't deduced immediately (ie: member functions of templates
or member functions defined out of line). In the common case of an
inline deduced return type function, GCC emits the DW_AT_type as the
deduced return type.
Currently GDB doesn't seem to behave too well with this debug info - it
treats the return type as 'void', even though the definition of the
function has the correctly deduced return type (I guess it sees the
return type the declaration has, doesn't understand it, and assumes
void). This means the function's ABI might be broken (non-trivial return
types, etc), etc.
Clang, on the other hand doesn't track this particular case of a
deducable return type that is deduced immediately versus one that is
deduced 'later'. So if we implement the DWARF5 representation, all
deducible return type functions would get adverse GDB behavior
(including deduced return type lambda functions, inline deduced return
type functions, etc).
Also, we can't just do this for auto types that are not deduced -
because Clang marks even the declaration's return type as deduced (&
provides the underlying type) once a definition is seen that allows the
deduction. So we have to ignore even deduced types - but we can't do
that for auto variables (because this representation only applies to
function declarations - variables and function definitions need the real
type so the function can be called, etc) so we'd need to add an extra
flag to the type unwrapping/creation code to indicate when we want to
see through deduced types and when we don't. It's also not as simple as
just checking at the top level when building a function type (for one
thing, we reuse the function type building for building function pointer
types which might also have 'auto' in them - but be the type of a
variable instead) because the auto might be arbitrarily deeply nested
("auto &", "auto (*)()", etc...)
So, with all that said, let's do the simple thing that works in existing
debuggers for now and treat these functions the same way we do function
templates and implicit special members: omit them from the member list,
since they can't be correctly called anyway (without knowing the return
type the ABI isn't know and a function call could put the arguments in
the wrong place) so they're not much use to the user.
At some point in the future, when GDB understands the DWARF5
representation better it might be worth plumbing through the extra type
builder handling to avoid looking through AutoType for some callers,
etc...
llvm-svn: 221704
2014-11-12 04:44:45 +08:00
|
|
|
|
|
|
|
|
auto foo::func() {
|
|
|
|
|
return 1;
|
|
|
|
|
}
|
2016-08-06 03:03:01 +08:00
|
|
|
|
|
|
|
|
namespace ns {
|
|
|
|
|
auto f2();
|
|
|
|
|
auto f3() {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
using ns::f2;
|
|
|
|
|
using ns::f3;
|