[test] Make tests pass regardless of gnu++14/gnu++17 default

GCC from 11 onwards defaults to -std=gnu++17 for C++ source files. We want to do the same
(https://discourse.llvm.org/t/c-objc-switch-to-

[test] Make tests pass regardless of gnu++14/gnu++17 default

GCC from 11 onwards defaults to -std=gnu++17 for C++ source files. We want to do the same
(https://discourse.llvm.org/t/c-objc-switch-to-gnu-17-as-the-default-dialect/64360).
Split RUN lines, adjust `-verify`, or add `__cplusplus < 201703L` or `-Wno-dynamic-exception-spec`,
so that tests will pass regardless of gnu++14/gnu++17 default.

We have a desire to mark a test compatible with multiple language standards.
There are ongoing discussions how to add markers in the long term:

* https://discourse.llvm.org/t/iterating-lit-run-lines/62596
* https://discourse.llvm.org/t/lit-run-a-run-line-multiple-times-with-different-replacements/64932

As a workaround in the short term, add lit substitutions `%std_cxx98-`,
`%std_cxx11-14`, etc. They can be used for tests which work across multiple
language standards. If a range has `n` standards, run lit multiple times, with
`LIT_CLANG_STD_GROUP=0`, `LIT_CLANG_STD_GROUP=1`, etc to cover all `n` standards.

Reviewed By: #clang-language-wg, aaron.ballman

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

show more ...

Implement P1766R1: diagnose giving non-C-compatible classes a typedef name for linkage purposes.

Summary:
Due to a recent (but retroactive) C++ rule change, only sufficiently
C-compatible classes ar

Implement P1766R1: diagnose giving non-C-compatible classes a typedef name for linkage purposes.

Summary:
Due to a recent (but retroactive) C++ rule change, only sufficiently
C-compatible classes are permitted to be given a typedef name for
linkage purposes. Add an enabled-by-default warning for these cases, and
rephrase our existing error for the case where we encounter the typedef
name for linkage after we've already computed and used a wrong linkage
in terms of the new rule.

Reviewers: rjmccall

Subscribers: cfe-commits

Tags: #clang

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

show more ...

[CXX] Exercise all paths through these tests.

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

llvm-svn: 365555

Add test for regression caused by reverted patch r315251.

llvm-svn: 315366

DR1113: anonymous namespaces formally give their contents internal linkage.

This doesn't affect our code generation in any material way -- we already give
such declarations internal linkage from a c

DR1113: anonymous namespaces formally give their contents internal linkage.

This doesn't affect our code generation in any material way -- we already give
such declarations internal linkage from a codegen perspective -- but it has
some subtle effects on code validity.

We suppress the 'L' (internal linkage) marker for mangled names in anonymous
namespaces, because it is redundant (the information is already carried by the
namespace); this deviates from GCC's behavior if a variable or function in an
anonymous namespace is redundantly declared 'static' (where GCC does include
the 'L'), but GCC's behavior is incoherent because such a declaration can be
validly declared with or without the 'static'.

We still deviate from the standard in one regard here: extern "C" declarations
in anonymous namespaces are still granted external linkage. Changing those does
not appear to have been an intentional consequence of the standard change in
DR1113.

llvm-svn: 314037

show more ...

Exclude invalid old decl from mismatching linkage assertion

This patch fixes PR18964. In linkage computation, assertion fails when
an old invalid declaration's linkage mismatches with the current
de

Exclude invalid old decl from mismatching linkage assertion

This patch fixes PR18964. In linkage computation, assertion fails when
an old invalid declaration's linkage mismatches with the current
decl's one.

llvm-svn: 203168

show more ...

Reinstate r185229, reverted in r185256, with a tweak: further ignore the
standard's rule that an extern "C" declaration conflicts with any entity in the
global scope with the same name. Now we only c

Reinstate r185229, reverted in r185256, with a tweak: further ignore the
standard's rule that an extern "C" declaration conflicts with any entity in the
global scope with the same name. Now we only care if the global scope entity is
a variable declaration (and so might have the same mangled name as the extern
"C" declaration). This has been reported as a standard defect.

Original commit message:

PR7927, PR16247: Reimplement handling of matching extern "C" declarations
across scopes.

When we declare an extern "C" name that is not a redeclaration of an entity in
the same scope, check whether it redeclares some extern "C" entity from another
scope, and if not, check whether it conflicts with a (non-extern-"C") entity in
the translation unit.

When we declare a name in the translation unit that is not a redeclaration,
check whether it conflicts with any extern "C" entities (possibly from other
scopes).

llvm-svn: 185281

show more ...

Revert r185229 as it breaks compilation of <windows.h>

llvm-svn: 185256

PR7927, PR16247: Reimplement handling of matching extern "C" declarations
across scopes.

When we declare an extern "C" name that is not a redeclaration of an entity in
the same scope, check whether

PR7927, PR16247: Reimplement handling of matching extern "C" declarations
across scopes.

When we declare an extern "C" name that is not a redeclaration of an entity in
the same scope, check whether it redeclares some extern "C" entity from another
scope, and if not, check whether it conflicts with a (non-extern-"C") entity in
the translation unit.

When we declare a name in the translation unit that is not a redeclaration,
check whether it conflicts with any extern "C" entities (possibly from other
scopes).

llvm-svn: 185229

show more ...

Fix PR16060.

The testcase in PR16060 points out that while template arguments can
show that a type is not externally visible, the standards still says
they have external linkage.

In terms of our im

Fix PR16060.

The testcase in PR16060 points out that while template arguments can
show that a type is not externally visible, the standards still says
they have external linkage.

In terms of our implementation, it means that we should merge just the
isExternallyVisible bit, not the formal linkage.

llvm-svn: 182962

show more ...

Fix linkage computation for derived types in inline functions.

John noticed that the fix for pr15930 (r181981) didn't handle indirect
uses of local types. For example, a pointer to local struct, or

Fix linkage computation for derived types in inline functions.

John noticed that the fix for pr15930 (r181981) didn't handle indirect
uses of local types. For example, a pointer to local struct, or a
function that returns it.

One way to implement this would be to recursively look for local
types. This would look a lot like the linkage computation itself for
types.

To avoid code duplication and utilize the existing linkage cache, this
patch just makes the computation of "type with no linkage but
externally visible because it is from an inline function" part of the
linkage computation itself.

llvm-svn: 182711

show more ...

Put friend decls in the correct context.

When we find a friend declaration we have to skip transparent contexts for doing
lookups, but we should not skip them when inserting the new decl if the look

Put friend decls in the correct context.

When we find a friend declaration we have to skip transparent contexts for doing
lookups, but we should not skip them when inserting the new decl if the lookup
found nothing.

Fixes PR15841.

llvm-svn: 180571

show more ...

Don't patch the storage class of static data members.

This removes a bit of patching that survived r178663. Without it we can produce
better a better error message for

const int a = 5;
static const

Don't patch the storage class of static data members.

This removes a bit of patching that survived r178663. Without it we can produce
better a better error message for

const int a = 5;
static const int a;

llvm-svn: 178795

show more ...

Use isExternalLinkage instead of hasExternalLinkage.

Having these not be the same makes an easy to misuse API. We should audit the
uses and probably rename to something like

foo->hasExternalLinkage

Use isExternalLinkage instead of hasExternalLinkage.

Having these not be the same makes an easy to misuse API. We should audit the
uses and probably rename to something like

foo->hasExternalLinkage():
The c++ standard one. That is UniqueExternalLinkage or ExternalLinkage.

foo->hasUniqueExternalLinkage():
Is UniqueExternalLinkage.

foo->hasCogeGenExternalLinkage():
Is ExternalLinkage.

llvm-svn: 178768

show more ...

Fix a recent linkage regression.

Now that we don't have a semantic storage class, use the linkage.

Thanks to Bruce Stephens for reporting this.

llvm-svn: 178766

Fix linkage related crash.

This test was exactly the opposite of what it should be. We should check if
there old decl has linkage (where it makes sense) and if the new decl has
the extern keyword.

Fix linkage related crash.

This test was exactly the opposite of what it should be. We should check if
there old decl has linkage (where it makes sense) and if the new decl has
the extern keyword.

llvm-svn: 178735

show more ...

Fix 41 of the 61 tests which fail with modules enabled: we were computing and
caching the linkage for a declaration before we set up its redeclaration chain,
when determining whether a declaration co

Fix 41 of the 61 tests which fail with modules enabled: we were computing and
caching the linkage for a declaration before we set up its redeclaration chain,
when determining whether a declaration could be a redeclaration of something
from an unimported submodule. We actually want to look at the declaration as if
it were not a redeclaration here, so compute the linkage but don't cache it.

llvm-svn: 178733

show more ...

Remove the hack that avoided mangling static functions in extern C contexts.

Weather we should give C language linkage to functions and variables with
internal linkage probably depends on how much c

Remove the hack that avoided mangling static functions in extern C contexts.

Weather we should give C language linkage to functions and variables with
internal linkage probably depends on how much code assumes it. The standard
says they should have no language linkage, but gcc and msvc assign them
C language linkage.

This commit removes the hack that was preventing the mangling on static
functions declare in extern C contexts. It is an experiment to see if we
can implement the rules in the standard.

If it turns out that many users depend on these functions and variables
having C language linkage, we should change isExternC instead and try
to convince the CWG to change the standard.

llvm-svn: 175937

show more ...

Partially revert r175117 so that we don't break assumptions about how
static functions in extern "C" contexts are mangled. Should fix the
bootstrap.

llvm-svn: 175132

merge hasCLanguageLinkage and isExternC. Keep the shorter name.

I added hasCLanguageLinkage while fixing some language linkage bugs some
time ago so that I wouldn't have to check all users of isExte

merge hasCLanguageLinkage and isExternC. Keep the shorter name.

I added hasCLanguageLinkage while fixing some language linkage bugs some
time ago so that I wouldn't have to check all users of isExternC. It turned
out to be a much longer detour than expected, but this patch finally
merges the two again. The isExternC function now implements just the
standard notion of having C language linkage.

llvm-svn: 175119

show more ...

Add a getLanguageLinkage method to VarDecls and FunctionDecls. Use it to fix
some cases where functions with no language linkage were being treated as having
C language linkage. In particular, don't

Add a getLanguageLinkage method to VarDecls and FunctionDecls. Use it to fix
some cases where functions with no language linkage were being treated as having
C language linkage. In particular, don't warn in

extern "C" {
static NonPod foo();
}

Since getLanguageLinkage checks the language linkage, the linkage computation
cannot use the language linkage. Break the loop by checking just the context
in the linkage computation.

llvm-svn: 175117

show more ...

Add a test from pr14898.

llvm-svn: 172283

Handle static functions being redeclared in function scope.

Fixes pr14861.

llvm-svn: 171978

Assert that redeclarations have the same linkage.

It is somewhat hard to test linkage, so I decided to try to add an assert. This
already found some interesting cases where there were different.

ll

Assert that redeclarations have the same linkage.

It is somewhat hard to test linkage, so I decided to try to add an assert. This
already found some interesting cases where there were different.

llvm-svn: 171585

show more ...

Reject overloading of two static extern C functions.

This patch moves hasCLanguageLinkage to be VarDecl and FunctionDecl methods
so that they can be used from SemaOverload.cpp and then fixes the log

Reject overloading of two static extern C functions.

This patch moves hasCLanguageLinkage to be VarDecl and FunctionDecl methods
so that they can be used from SemaOverload.cpp and then fixes the logic
in Sema::IsOverload.

llvm-svn: 171193

show more ...