| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 171906
|
|
|
|
| |
llvm-svn: 171902
|
|
|
|
| |
llvm-svn: 171899
|
|
|
|
| |
llvm-svn: 171894
|
|
|
|
|
|
| |
Thanks to Dmitri Gribenko for the suggestion.
llvm-svn: 171889
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In the source
static void f();
static void f();
template<typename T>
static void g() {
f();
}
static void f() {
}
void h() {
g<int>();
}
the call to f refers to the second decl, but it is only marked used at the end
of the translation unit during instantiation, after the third f decl has been
linked in.
With this patch we mark all subsequent decls used, so that it is easy to check
if a symbol is used or not.
llvm-svn: 171888
|
|
|
|
|
|
|
| |
attribute when determining whether we need to see an implementation of
a property. Fixes <rdar://problem/12958191>.
llvm-svn: 171877
|
|
|
|
|
|
|
| |
The availability implies default visibility, so it can change the computed
visibility.
llvm-svn: 171840
|
|
|
|
|
|
| |
Fixes <rdar://problem/12322000>.
llvm-svn: 171831
|
|
|
|
|
|
|
| |
perform the semantic checks associated with the destruction of that temporary.
It'll be destroyed at the end of the constructor.
llvm-svn: 171818
|
|
|
|
| |
llvm-svn: 171817
|
|
|
|
|
|
| |
can create a VLA of class type. Fixes <rdar://problem/12151822>.
llvm-svn: 171783
|
|
|
|
| |
llvm-svn: 171782
|
|
|
|
|
|
| |
Patch by Nick Lewycky. Fixes pr8703.
llvm-svn: 171781
|
|
|
|
|
|
|
| |
list of classes, etc., make sure to look into protocol
definitions. // rdar://12958878
llvm-svn: 171777
|
|
|
|
|
|
|
|
|
|
| |
with respect to the lower "left-hand-side bitwidth" bits, even when negative);
see OpenCL spec 6.3j. This patch both implements this behaviour in the code
generator and "constant folding" bits of Sema, and also prevents tests
to detect undefinedness in terms of the weaker C99 or C++ specifications
from being applied.
llvm-svn: 171755
|
|
|
|
|
|
|
|
| |
<objc/Protocol.h>. Caused by my recent changes for
various builtin declarations of objc_msgSendSuper
variety. // rdar://12489098
llvm-svn: 171638
|
|
|
|
|
|
|
| |
to match those foung in objc.h an avoid spurious warnings.
// rdar://12489098
llvm-svn: 171492
|
|
|
|
|
|
|
|
| |
To do so we have to wait until we know that the type of a variable has been
deduced. Sema::FinalizeDeclaration is the first callback that is used for
decl with or without initializers.
llvm-svn: 171458
|
|
|
|
| |
llvm-svn: 171457
|
|
|
|
| |
llvm-svn: 171402
|
|
|
|
|
|
| |
nearby 'C++0x' comments.
llvm-svn: 171372
|
|
|
|
| |
llvm-svn: 171367
|
|
|
|
| |
llvm-svn: 171267
|
|
|
|
| |
llvm-svn: 171263
|
|
|
|
|
|
|
|
| |
This fixes pr14736. It is fairly ugly, but I don't think we can do much better
as we have to wait at least until the end of the typedef to know if the
function will have external linkage or not.
llvm-svn: 171240
|
|
|
|
| |
llvm-svn: 171239
|
|
|
|
| |
llvm-svn: 171238
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
function is selected by overload resolution.
llvm-svn: 171190
|
|
|
|
|
|
|
| |
The language linkage of redeclarations must match. GCC was already reporting
an error for this.
llvm-svn: 171139
|
|
|
|
|
|
|
| |
Template instantiation can set the canonical decl to used after subsequent
decls have been chained, so we have to check that too.
llvm-svn: 171088
|
|
|
|
|
|
| |
This fixes pr14691, which I think is a regression from r168519.
llvm-svn: 171077
|
|
|
|
|
|
|
|
| |
Changed getLocStart() and getLocEnd() to be required for Stmts, and make
getSourceRange() optional. The default implementation for getSourceRange()
is build the range by calling getLocStart() and getLocEnd().
llvm-svn: 171067
|
|
|
|
|
|
| |
calling convention is already implemented in LLVM.
llvm-svn: 171056
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the body of a functions. The problem was that hasBody looks at the entire chain
and causes problems to -fvisibility-inlines-hidden if the cache was not
invalidated.
Original message:
Cache visibility of decls.
This unifies the linkage and visibility caching. I first implemented this when
working on pr13844, but the previous fixes removed the performance advantage of
this one.
This is still a step in the right direction for making linkage and visibility
cheap to use.
llvm-svn: 171053
|
|
|
|
|
|
| |
It broke stage2.
llvm-svn: 171050
|
|
|
|
|
|
|
|
|
|
|
| |
This unifies the linkage and visibility caching. I first implemented this when
working on pr13844, but the previous fixes removed the performance advantage of
this one.
This is still a step in the right direction for making linkage and visibility
cheap to use.
llvm-svn: 171048
|
|
|
|
| |
llvm-svn: 170992
|
|
|
|
|
|
| |
it might instead be a TranslationUnitDecl.
llvm-svn: 170976
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was removed with -Wunique-enum, which is still removed. The
corresponding thread on cfe-comments for that warning is here:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-September/024224.html
If we get specific user feedback for -Wduplicate-enum we can evaluate
whether or not to keep it.
llvm-svn: 170974
|
|
|
|
|
|
|
| |
This simplifies some diagnostic logic in checkUnsafeAssignLiteral(),
hopefully making it less error prone.
llvm-svn: 170945
|
|
|
|
| |
llvm-svn: 170938
|
|
|
|
| |
llvm-svn: 170933
|
|
|
|
|
|
|
|
|
|
| |
Along the way, fix a bug in CheckLiteralKind(), previously in diagnoseObjCLiteralComparison, where we didn't ignore parentheses
in boxed expressions for purpose of classification.
In other words, both @42 and @(42) should be classified as numeric
literals.
llvm-svn: 170931
|
|
|
|
|
|
|
|
| |
with other diagnostics.
No immediate (intended) functionality change.
llvm-svn: 170930
|
|
|
|
| |
llvm-svn: 170920
|
|
|
|
| |
llvm-svn: 170919
|
|
|
|
| |
llvm-svn: 170903
|
|
|
|
|
|
|
|
| |
CXXScalarValueInitExpr (or an ImplicitValueInitExpr), strip it back down to an
empty pair of parentheses so that the initialization code can tell that we're
performing value-initialization.
llvm-svn: 170867
|