maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGenCXX/debug-info-cxx1y.cpp

21 lines
903 B
C++
Raw Normal View History

clang/test/CodeGenCXX/debug-info-cxx1y.cpp: Add %itanium_abi_triple for incompatible MS targets. llvm-svn: 221741
2014-11-12 07:51:53 +08:00
// RUN: %clang_cc1 -triple %itanium_abi_triple -emit-llvm-only -std=c++14 -emit-llvm -g %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
// CHECK: [[EMPTY:![0-9]*]] = metadata !{}
// CHECK: \00foo\00{{.*}}, metadata [[EMPTY]], {{.*}}} ; [ DW_TAG_structure_type ]
// FIXME: The context of this definition should be the CU/file scope, not the class.
// CHECK: metadata !"_ZTS3foo", metadata [[SUBROUTINE_TYPE:![0-9]*]], {{.*}}, metadata [[FUNC_DECL:![0-9]*]], metadata {{![0-9]*}}} ; [ DW_TAG_subprogram ] {{.*}} [def] [func]
// CHECK: [[SUBROUTINE_TYPE]] = {{.*}}, metadata [[TYPE_LIST:![0-9]*]],
// CHECK: [[TYPE_LIST]] = metadata !{metadata [[INT:![0-9]*]]}
// CHECK: [[INT]] = {{.*}} ; [ DW_TAG_base_type ] [int]
// CHECK: [[FUNC_DECL]] = {{.*}}, metadata !"_ZTS3foo", metadata [[SUBROUTINE_TYPE]], {{.*}}} ; [ DW_TAG_subprogram ] {{.*}} [func]
PR16091: Error when attempting to emit debug info for undeduced auto return types Perhaps we should just suppress this, rather than erroring, but since we have the infrastructure for it I figured I'd use it - if this is determined to be not the right thing we should probably remove that infrastructure entirely. I guess it's lying around from the early days of implementing debug info support. llvm-svn: 182673
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();
PR16091: Error when attempting to emit debug info for undeduced auto return types Perhaps we should just suppress this, rather than erroring, but since we have the infrastructure for it I figured I'd use it - if this is determined to be not the right thing we should probably remove that infrastructure entirely. I guess it's lying around from the early days of implementing debug info support. llvm-svn: 182673
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;
}