| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
selectany only applies to externally visible global variables. It has
the effect of making the data weak_odr.
The MSDN docs suggest that unused definitions can only be dropped at
linktime, so Clang uses weak instead of linkonce. MSVC optimizes away
references to constant selectany data, so it must assume that there is
only one definition, hence weak_odr.
Reviewers: espindola
Differential Revision: http://llvm-reviews.chandlerc.com/D814
llvm-svn: 182266
|
|
|
|
|
|
| |
crash on an explicit specialization of a member function in a class scope.
llvm-svn: 181971
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch renames getLinkage to getLinkageInternal. Only code that
needs to handle UniqueExternalLinkage specially should call this.
Linkage, as defined in the c++ standard, is provided by
getFormalLinkage. It maps UniqueExternalLinkage to ExternalLinkage.
Most places in the compiler actually want isExternallyVisible, which
handles UniqueExternalLinkage as internal.
llvm-svn: 181677
|
|
|
|
| |
llvm-svn: 181627
|
|
|
|
|
|
|
| |
substitute 'void' into the return type rather than replacing it with 'void', so
that we maintain the 'auto' type sugar.
llvm-svn: 181584
|
|
|
|
|
|
|
|
| |
code as well.
rdar://13829073
llvm-svn: 181345
|
|
|
|
| |
llvm-svn: 181166
|
|
|
|
|
|
|
| |
I was not able to find a case (other than the fix in r181163) where this
makes a difference, but it is a more obviously correct API to have.
llvm-svn: 181165
|
|
|
|
|
|
|
| |
This fixes pr14958. I will audit other calls to isExternCContext to see
if there are any similar bugs left.
llvm-svn: 181163
|
|
|
|
|
|
|
|
| |
constructor from None
Patch by Robert Wilhelm.
llvm-svn: 181139
|
|
|
|
| |
llvm-svn: 181113
|
|
|
|
|
|
|
| |
Missing (somewhat ironically) is support for the new deduction rules
in lambda functions, plus PCH support for return type patching.
llvm-svn: 181108
|
|
|
|
|
|
| |
diagnostic.
llvm-svn: 181103
|
|
|
|
|
|
| |
it when visiting such subexpressions.
llvm-svn: 181046
|
|
|
|
|
|
|
|
| |
InitializationSequence::Diagnose()
Patch by Robert Wilhelm.
llvm-svn: 181022
|
|
|
|
|
|
| |
Patch by Ismail Pazarbasi.
llvm-svn: 181011
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
arguments as expressions.
This change partly addresses a heinous problem we have with the
parsing of attribute arguments that are a lone identifier. Previously,
we would end up parsing the 'align' attribute of this as an expression
"(Align)":
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align((Align)))) char storage[Size];
};
while this would parse as a "parameter name" 'Align':
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align(Align))) char storage[Size];
};
The code that handles the alignment attribute would completely ignore
the parameter name, so the while the first of these would do what's
expected, the second would silently be equivalent to
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align)) char storage[Size];
};
i.e., use the maximal alignment rather than the specified alignment.
Address this by sniffing the "Args" provided in the TableGen
description of attributes. If the first argument is "obviously"
something that should be treated as an expression (rather than an
identifier to be matched later), parse it as an expression.
Fixes <rdar://problem/13700933>.
llvm-svn: 180973
|
|
|
|
| |
llvm-svn: 180972
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
arguments as expressions.
This change partly addresses a heinous problem we have with the
parsing of attribute arguments that are a lone identifier. Previously,
we would end up parsing the 'align' attribute of this as an expression
"(Align)":
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align((Align)))) char storage[Size];
};
while this would parse as a "parameter name" 'Align':
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align(Align))) char storage[Size];
};
The code that handles the alignment attribute would completely ignore
the parameter name, so the while the first of these would do what's
expected, the second would silently be equivalent to
template<unsigned Size, unsigned Align>
class my_aligned_storage
{
__attribute__((align)) char storage[Size];
};
i.e., use the maximal alignment rather than the specified alignment.
Address this by sniffing the "Args" provided in the TableGen
description of attributes. If the first argument is "obviously"
something that should be treated as an expression (rather than an
identifier to be matched later), parse it as an expression.
Fixes <rdar://problem/13700933>.
llvm-svn: 180970
|
|
|
|
| |
llvm-svn: 180808
|
|
|
|
|
|
|
|
| |
are now two distinct canonical 'AutoType's: one is the undeduced 'auto'
placeholder type, and the other is a deduced-but-dependent type. All
deduced-to-a-non-dependent-type cases are still non-canonical.
llvm-svn: 180789
|
|
|
|
|
|
| |
Patch by Robert Wilhelm.
llvm-svn: 180682
|
|
|
|
| |
llvm-svn: 180610
|
|
|
|
|
|
|
|
|
|
| |
Instead, we check for one line extern "C" context in linkage computation and
when deciding if a variable is a definition.
This hopefully completes the transition to having "as written" semantics for
hasExternalStorage.
llvm-svn: 180258
|
|
|
|
|
|
|
|
| |
statement in constexpr functions. Everything which doesn't require variable
mutation is also allowed as an extension in C++11. 'void' becomes a literal
type to support constexpr functions which return 'void'.
llvm-svn: 180022
|
|
|
|
|
|
|
|
|
| |
C++1y, so stop adding the 'const' there. Provide a compatibility warning for
code relying on this in C++11, with a fix-it hint. Update our lazily-written
tests to add the const, except for those ones which were testing our
implementation of this rule.
llvm-svn: 179969
|
|
|
|
|
|
| |
Patch by Halfdan Ingvarsson!
llvm-svn: 179598
|
|
|
|
|
|
|
|
| |
It was being used correctly, but it is a very dangerous API to have around.
Instead, move the logic from the filtering to when we are deciding if we should
link two decls.
llvm-svn: 179523
|
|
|
|
|
|
| |
_Thread_local nor __thread.)
llvm-svn: 179517
|
|
|
|
| |
llvm-svn: 179516
|
|
|
|
|
|
| |
or non-trivial destructor.
llvm-svn: 179491
|
|
|
|
|
|
|
|
|
| |
Invalid redeclarations of valid explicit declarations shouldn't
take the same path as redeclarations of implicit declarations,
and invalid local extern declarations shouldn't foul things up
for everybody else.
llvm-svn: 179482
|
|
|
|
|
|
| |
the AST.
llvm-svn: 179447
|
|
|
|
|
|
|
|
|
| |
local-extern redeclaration; type refinements, default arguments,
etc. must all be locally scoped.
rdar://13535367
llvm-svn: 179430
|
|
|
|
|
|
| |
semantics as __thread for now.
llvm-svn: 179424
|
|
|
|
|
|
|
|
|
| |
invalid enum.
Fixes PR15693. A null check on a pointer returned from cast<> is a very dubious
construct, do we have a checker for this somewhere?
llvm-svn: 178975
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New rule:
- Method decls in @implementation are considered "redeclarations"
and inherit deprecated/availability from the @interface.
- All other cases are consider overrides, which do not inherit
deprecated/availability. For example:
(a) @interface redeclares a method in an adopted protocol.
(b) A subclass redeclares a method in a superclass.
(c) A protocol redeclares a method from another protocol it adopts.
The idea is that API authors should have the ability to easily
move availability/deprecated up and down a class/protocol hierarchy.
A redeclaration means that the availability/deprecation is a blank
slate.
Fixes <rdar://problem/13574571>
llvm-svn: 178937
|
|
|
|
|
|
| |
address space in OpenCL.
llvm-svn: 178906
|
|
|
|
| |
llvm-svn: 178813
|
|
|
|
|
|
| |
address space in OpenCL.
llvm-svn: 178811
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Now that we don't have a semantic storage class, use the linkage.
Thanks to Bruce Stephens for reporting this.
llvm-svn: 178766
|
|
|
|
|
|
| |
keep the call at the current location.
llvm-svn: 178741
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This mostly reverts 178733, but keeps the tests.
I don't claim to understand how hidden sub modules work or when we need to see
them (is that documented?), but this has the same semantics and avoids adding
hasExternalLinkageUncached which has the same foot gun potential as the old
hasExternalLinkage.
Last but not least, not computing linkage when it is not needed is more
efficient.
llvm-svn: 178739
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
declaration. Patch by Stephen Lin!
llvm-svn: 178698
|
|
|
|
|
|
|
|
|
|
|
| |
http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb went back green
before it processed the reverted 178663, so it could not have been the culprit.
Revert "Revert 178663."
This reverts commit 4f8a3eb2ce5d4ba422483439e20c8cbb4d953a41.
llvm-svn: 178682
|
|
|
|
|
|
|
|
|
|
| |
Looks like it broke http://lab.llvm.org:8011/builders/clang-x86_64-darwin10-gdb
Revert "Don't compute a patched/semantic storage class."
This reverts commit 8f187f62cb0487d31bc4afdfcd47e11fe9a51d05.
llvm-svn: 178681
|