| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
No (intended) functionality change.
llvm-svn: 176726
|
|
|
|
|
|
| |
Objective-C object type <rdar://problem/13338107>.
llvm-svn: 176665
|
|
|
|
|
|
| |
Fixes <rdar://problem/13330126>.
llvm-svn: 176663
|
|
|
|
| |
llvm-svn: 176607
|
|
|
|
|
|
|
| |
can't have default arguments even though it's a parameter-declaration-clause in
a function declaration.
llvm-svn: 176542
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 176469
|
|
|
|
|
|
| |
we are looking at.
llvm-svn: 176414
|
|
|
|
| |
llvm-svn: 176122
|
|
|
|
|
|
| |
internal linkage.
llvm-svn: 175903
|
|
|
|
|
|
| |
Patch by Alexander Zinenko!
llvm-svn: 175890
|
|
|
|
|
|
|
|
| |
the normal attribute-merging path, because we can't merge alignment attributes
without knowing the complete set of alignment attributes which apply to a
particular declaration.
llvm-svn: 175861
|
|
|
|
| |
llvm-svn: 175860
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
control the visibility of a type for the purposes of RTTI
and template argument restrictions independently of how
visibility propagates to its non-type member declarations.
Also fix r175326 to not ignore template argument visibility
on a template explicit instantiation when a member has
an explicit attribute but the instantiation does not.
The type_visibility work is rdar://11880378
llvm-svn: 175587
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The TypeLoc hierarchy used the llvm::cast machinery to perform undefined
behavior by casting pointers/references to TypeLoc objects to derived types
and then using the derived copy constructors (or even returning pointers to
derived types that actually point to the original TypeLoc object).
Some context is in this thread:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-December/056804.html
Though it's spread over a few months which can be hard to read in the mail
archive.
llvm-svn: 175462
|
|
|
|
| |
llvm-svn: 175265
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
restrictions.
llvm-svn: 174601
|
|
|
|
|
|
| |
module import occurred.
llvm-svn: 174191
|
|
|
|
|
|
| |
defined. Fixes PR14993!
llvm-svn: 174158
|
|
|
|
|
|
| |
Also support alignas(0), which C++11 and C11 require us to ignore.
llvm-svn: 174157
|
|
|
|
|
|
|
| |
filter the elements before emitting them into a PCH. No user-visible
functionality change, except that PCH files may be smaller?
llvm-svn: 174034
|
|
|
|
| |
llvm-svn: 174032
|
|
|
|
|
|
| |
a test case.
llvm-svn: 173963
|
|
|
|
|
|
| |
an attribute for consistency with our other noreturn mechanisms.
llvm-svn: 173898
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the member has an initializer, assume it was probably intended to be static
and suggest/recover with that.
If the member doesn't have an initializer, assume it was probably intended to
be const instead of constexpr and suggest that.
(if the attempt to apply these changes fails, don't make any suggestion &
produce the same diagnostic experience as before. The only case where this can
come up that I know of is with a mutable constexpr with an initializer, since
mutable is incompatible with static (but it's already incompatible with
const anyway))
llvm-svn: 173873
|
|
|
|
| |
llvm-svn: 173841
|
|
|
|
|
|
|
| |
Fix to change r173414 that lead to Clang changing const to constexpr even under
-Wno-static-float-init.
llvm-svn: 173835
|
|
|
|
|
|
|
|
|
|
|
| |
TopLevelDeclInObjCContainer bit.
Fixes accurately getting a cursor inside an objc container containing a struct definition,
from a PCH/preamble file.
rdar://12584613
llvm-svn: 173811
|