[Clang] Add -no-opaque-pointers to more tests (NFC)

This adds the flag to more tests that were not caught by the
mass-migration in 532dc62b907554b3f07f17205674aa71e76fc863.

DebugInfo: workaround for context-sensitive use of non-type-template-parameter integer suffixes

There's a nuanced check about when to use suffixes on these integer
non-type-template-parameters, but

DebugInfo: workaround for context-sensitive use of non-type-template-parameter integer suffixes

There's a nuanced check about when to use suffixes on these integer
non-type-template-parameters, but when rebuilding names for
-gsimple-template-names there isn't enough data in the DWARF to
determine when to use suffixes or not. So turn on suffixes always to
make it easy to match up names in llvm-dwarfdump --verify.

I /think/ if we correctly modelled auto non-type-template parameters
maybe we could put suffixes only on those. But there's also some logic
in Clang that puts the suffixes on overloaded functions - at least
that's what the parameter says (see D77598 and printTemplateArguments
"TemplOverloaded" parameter) - but I think maybe it's for anything that
/can/ be overloaded, not necessarily only the things that are overloaded
(the argument value is hardcoded at the various callsites, doesn't seem
to depend on overload resolution/searching for overloaded functions). So
maybe with "auto" modeled more accurately, and differentiating between
function templates (always using type suffixes there) and class/variable
templates (only using the suffix for "auto" types) we could correctly
use integer type suffixes only in the minimal set of cases.

But that seems all too much fuss, so let's just put integer type
suffixes everywhere always in the debug info of integer non-type
template parameters in template names.

(more context:
* https://reviews.llvm.org/D77598#inline-1057607
* https://groups.google.com/g/llvm-dev/c/ekLMllbLIZg/m/-dhJ0hO1AAAJ )

Differential Revision: https://reviews.llvm.org/D111477

show more ...

DebugInfo: Don't use preferred template names in debug info

Using the preferred name creates a mismatch between the textual name of
a type and the DWARF tags describing the parameters as well as pos

DebugInfo: Don't use preferred template names in debug info

Using the preferred name creates a mismatch between the textual name of
a type and the DWARF tags describing the parameters as well as possible
inconsistency between DWARF producers (like Clang and GCC, or
older/newer Clang versions, etc).

show more ...

DebugInfo: Don't suppress inline namespaces when printing template template parameter names

Print nullptr_t namespace qualified within std::

This improves diagnostic (& important to me, DWARF) accuracy - otherwise
there could be ambiguities between "std::nullptr_t" and some user-defined
ty

Print nullptr_t namespace qualified within std::

This improves diagnostic (& important to me, DWARF) accuracy - otherwise
there could be ambiguities between "std::nullptr_t" and some user-defined
type that's /actually/ "nullptr_t" defined in the global namespace.

Differential Revision: https://reviews.llvm.org/D110044

show more ...

DebugInfo: Add support for template parameters with reference qualifiers

Followon from the previous commit supporting cvr qualifiers.

DebugInfo: Add support for template parameters with qualifiers

eg: t1<void () const> - DWARF doesn't have a particularly nice way to
encode this, for real member function types (like `void (t1::*)()

DebugInfo: Add support for template parameters with qualifiers

eg: t1<void () const> - DWARF doesn't have a particularly nice way to
encode this, for real member function types (like `void (t1::*)()
const`) the const-ness is encoded in the type of the artificial first
parameter. But `void () const` has no parameters, so encode it like a
normal const-qualified type, using DW_TAG_const_type. (similarly for
restrict and volatile)

Reference qualifiers (& and &&) coming in a separate commit shortly.

show more ...

[DIBuilder] Do not replace empty enum types

It looks like this array was missed in 4276d4a8d08b7640eb57cabf6988a5cf65b228b6

Fixed tests that expected `elements` to be empty or depeneded on the orde

[DIBuilder] Do not replace empty enum types

It looks like this array was missed in 4276d4a8d08b7640eb57cabf6988a5cf65b228b6

Fixed tests that expected `elements` to be empty or depeneded on the order of the empty DINode.

Reviewed By: aprantl

Differential Revision: https://reviews.llvm.org/D107024

show more ...

DebugInfo: Correct printing empty template parameter packs

Empty packs in the non-final position would result in an extra ", ".
Empty packs in the final position would result in missing the space
be

DebugInfo: Correct printing empty template parameter packs

Empty packs in the non-final position would result in an extra ", ".
Empty packs in the final position would result in missing the space
between trailing >>.

show more ...

DebugInfo: Name class templates with default arguments consistently (both direct naming, and as a template argument for a function template)

It's noteworthy that GCC has the same bug here, which is

DebugInfo: Name class templates with default arguments consistently (both direct naming, and as a template argument for a function template)

It's noteworthy that GCC has the same bug here, which is a bit
surprising. Both Clang and GCC's bug is only for function template
arguments that are themselves templates with default template arguments
(f1<t1<int[, missing_default_here]>>). Probably because function name
matching isn't generally necessary - whereas type matching is necessary
for DWARF consumers to associate declarations and definitions across
translation units, so the bug's been addressed there already - but
continued to exist for function templates since it's fairly benign
there.

I came across this while working on a change that could reconstitute
these pretty printed names based on the rest of the DWARF, reducing the
size of the DWARF by not having to encode all the template parameters in
the name string. That reconstitution code can't tell the difference
between a defaulted argument or not, so couldn't create the current
buggy-ish output.

Making the names more consistent between direct and indirect references,
and between function and class templates seems all to the good.

(I fixed the function template version of this a few years back in
9fdd09a4ccd01feb8e00be22b17e944e46807746 - clearly I should've looked
more closely and generalized the code better so it only had to be fixed
once - well, doing that here now)

show more ...

DebugInfo: Include inline namespaces in template specialization parameter names

This ensures these types have distinct names if they are distinct types
(eg: if one is an instantiation with a type in

DebugInfo: Include inline namespaces in template specialization parameter names

This ensures these types have distinct names if they are distinct types
(eg: if one is an instantiation with a type in one inline namespace, and
another from a type with the same simple name, but in a different inline
namespace).

show more ...

PR48169: Fix crash generating debug info for class non-type template
parameters.

It appears that LLVM isn't able to generate a DW_AT_const_value for a
constant of class type, but if it could, we'd m

PR48169: Fix crash generating debug info for class non-type template
parameters.

It appears that LLVM isn't able to generate a DW_AT_const_value for a
constant of class type, but if it could, we'd match GCC's debug info in
this case, and in the interim we no longer crash.

show more ...

[c++20] For P1907R1: Add checking for structural types for non-type
template parameters.

No support for the new kinds of non-type template argument yet.

This is not entirely NFC for prior language

[c++20] For P1907R1: Add checking for structural types for non-type
template parameters.

No support for the new kinds of non-type template argument yet.

This is not entirely NFC for prior language modes: we have historically
incorrectly accepted rvalue references as the types of non-type template
parameters. Such invalid code is now rejected.

show more ...

Don't print `&` as part of reference template arguments.

In passing, also generalize the mechanism used to allow Decl's printName
functions to override qualified name printing.

Recommit r324107 again.

The difference from the previous try is that we no longer directly
access function declarations from position independent executables. It
should work, but currently doesn't w

Recommit r324107 again.

The difference from the previous try is that we no longer directly
access function declarations from position independent executables. It
should work, but currently doesn't with some linkers.

It now includes a fix to not mark available_externally definitions as
dso_local.

Original message:

Start setting dso_local in clang.

This starts adding dso_local to clang.

The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go
away. My objective for now is to move enough of it to clang to remove
the need for the TargetMachine one to handle PIE copy relocations and
-fno-plt. With that it should then be easy to implement a
-fno-copy-reloc in clang.

This patch just adds the cases where we assume a symbol to be local
based on the file being compiled for an executable or a shared
library.

llvm-svn: 324535

show more ...

Revert "Recommit r324107."

This reverts commit r324500.

The bots found two failures:

ThreadSanitizer-x86_64 :: Linux/pie_no_aslr.cc
ThreadSanitizer-x86_64 :: pie_test.cc

when using gold.

Revert "Recommit r324107."

This reverts commit r324500.

The bots found two failures:

ThreadSanitizer-x86_64 :: Linux/pie_no_aslr.cc
ThreadSanitizer-x86_64 :: pie_test.cc

when using gold. The issue is a limitation in gold when building pie
binaries. I will investigate how to work around it.

llvm-svn: 324505

show more ...

Recommit r324107.

It now includes a fix to not mark available_externally definitions as
dso_local.

Original message:

Start setting dso_local in clang.

This starts adding dso_local to clang.

The

Recommit r324107.

It now includes a fix to not mark available_externally definitions as
dso_local.

Original message:

Start setting dso_local in clang.

This starts adding dso_local to clang.

The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go
away. My objective for now is to move enough of it to clang to remove
the need for the TargetMachine one to handle PIE copy relocations and
-fno-plt. With that it should then be easy to implement a
-fno-copy-reloc in clang.

This patch just adds the cases where we assume a symbol to be local
based on the file being compiled for an executable or a shared
library.

llvm-svn: 324500

show more ...

Revert "Start setting dso_local in clang."

This reverts commit r324107.

I will have to test it on OS X.

llvm-svn: 324108

Start setting dso_local in clang.

This starts adding dso_local to clang.

The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go
away. My objective for now is to move enough of it to

Start setting dso_local in clang.

This starts adding dso_local to clang.

The hope is to eventually have TargetMachine::shouldAssumeDsoLocal go
away. My objective for now is to move enough of it to clang to remove
the need for the TargetMachine one to handle PIE copy relocations and
-fno-plt. With that it should then be easy to implement a
-fno-copy-reloc in clang.

This patch just adds the cases where we assume a symbol to be local
based on the file being compiled for an executable or a shared
library.

llvm-svn: 324107

show more ...

Adapt testcases to LLVM change r312144 in DIGlobalVariableExpression

llvm-svn: 312148

Update for LLVM global variable debug info API change.

This reapplies r289921.

llvm-svn: 290155

Revert "Update for LLVM global variable debug info API change."

This reverts commit r289921.

llvm-svn: 289984

Update for LLVM global variable debug info API change.

llvm-svn: 289921

Revert "Update for LLVM global variable debug info API change."

This reverts commit 289901 while investigating bot breakage.

llvm-svn: 289908

Update for LLVM global variable debug info API change.

llvm-svn: 289901