| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
For variables and functions clang used to store two storage classes. The one
"as written" in the code and a patched one, which, for example, propagates
static to the following decls.
This apparently is from the days clang lacked linkage computation. It is now
redundant and this patch removes it.
llvm-svn: 178663
|
|
|
|
|
|
|
|
|
|
| |
Doxygen treats "@command" the same as "\command" in a doc comment, so
whenever we talk about Objective-C things like "@interface" we have to
make sure to escape them.
Let's try to keep Clang -Wdocumentation-clean!
llvm-svn: 178603
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
variable in a C99 inline (but not static-inline or extern-inline)
function definition.
The standard doesn't actually say that this doesn't apply to
"extern inline" definitions, but that seems like a useful extension,
and it at least doesn't have the obvious flaw that a static
mutable variable in an externally-available definition does.
rdar://13535367
llvm-svn: 178520
|
|
|
|
|
|
|
| |
specifier for an enumeration. Also fix a crash-on-invalid if a non-dependent
name specifier is used to declare an enum template.
llvm-svn: 178502
|
|
|
|
|
|
|
|
|
| |
visible. There's a lot of potential badness in how we're modelling
these things, but getting this much correct is reasonably easy.
rdar://13535367
llvm-svn: 178488
|
|
|
|
| |
llvm-svn: 178335
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already avoided warning for
extern "C" const char *Version_string = "2.9";
now we also don't produce any warnings for
extern "C" {
extern const char *Version_string2 = "2.9";
}
llvm-svn: 178333
|
|
|
|
|
|
|
| |
To do this, thread DiagnosticErrorTrap's hasUnrecoverableErrorOccurred through
to Scope.
llvm-svn: 178294
|
|
|
|
|
|
| |
sugar for the _Atomic type specifier.
llvm-svn: 178210
|
|
|
|
|
|
| |
class types.
llvm-svn: 177987
|
|
|
|
|
|
| |
underlying type in Objective-C (as well as C++11).
llvm-svn: 177930
|
|
|
|
|
|
|
|
|
|
|
|
| |
picking up cleanups from earlier in the statement. Also fix a
crash-on-invalid where a reference to an invalid decl from an
enclosing scope was causing an expression to fail to build, but
only *after* a cleanup was registered from that statement,
causing an assertion downstream.
The crash-on-valid is rdar://13459289.
llvm-svn: 177692
|
|
|
|
| |
llvm-svn: 177665
|
|
|
|
|
|
| |
and warn when a newly-imported module conflicts with an already-imported module.
llvm-svn: 177577
|
|
|
|
|
|
|
|
| |
performing unqualified lookup for a friend class declaration.
rdar://13393749
llvm-svn: 177473
|
|
|
|
|
|
| |
definition. Bump some related diagnostics from warning to extension in C++, since they're errors there. Add some missing checks for function specifiers on non-function declarations.
llvm-svn: 177335
|
|
|
|
|
|
| |
on first declaration only. // rdar://13364028
llvm-svn: 177127
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch we would compute the linkage lazily and cache it. When the
AST was modified in ways that could change the value, we would invalidate the
cache.
That was fairly brittle, since any code could ask for the a linkage before
the correct value was available.
We should change the API to one where the linkage is computed explicitly and
trying to get it when it is not available asserts.
This patch is a first step in that direction. We still compute the linkage
lazily, but instead of invalidating a cache, we assert that the AST
modifications didn't change the result.
llvm-svn: 176999
|
|
|
|
| |
llvm-svn: 176896
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
extern "C" {
void test5_f() {
extern int test5_b;
}
}
static float test5_b;
This patch makes us report one for
extern "C" {
void test6_f() {
extern int test6_b;
}
}
extern "C" {
static float test6_b;
}
Not because we think the declaration would be extern C, but because of the rule:
An entity with C language linkage shall not be declared with the same name as an entity in global scope...
We were just not looking past the extern "C" to see if the decl was in global
scope.
llvm-svn: 176875
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Without this patch we produce an error for
extern "C" {
void f() {
extern int b;
}
}
extern "C" {
extern float b;
}
but not for
extern "C" {
void f() {
extern int b;
}
}
extern "C" {
float b;
}
llvm-svn: 176867
|