| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
weak reference.
Thanks to Jordan Rose and John McCall for their sage code review.
Fixes <rdar://problem/12569201>.
llvm-svn: 170864
|
|
|
|
|
|
|
|
| |
This is just a minor bit of refactoring, but it is nice cleanup for
the subsequent patch that adds warning support for assigning literals
to weak variables.
llvm-svn: 170863
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we are visiting the extern declaration of 'i' in
static int i = 99;
int foo() {
extern int i;
return i;
}
We should not try to handle it as if it was an function static. That is, we
must consider the written storage class.
Fixing this then exposes that the assert in EmitGlobalVarDeclLValue and the
if leading to its call are not completely accurate. They were passing before
because the second decl was marked as having external storage. I changed them
to check the linkage, which I find easier to understand.
Last but not least, there is something strange going on with cuda and opencl.
My guess is that the linkage computation for these languages needs to be
audited, but I didn't want to change that in this patch so I just updated
the storage classes to keep the current behavior.
Thanks to Reed Kotler for reporting this.
llvm-svn: 170827
|
|
|
|
|
|
|
|
| |
literal."
Per code feedback, I want to see if there is a more general way to do this.
llvm-svn: 170777
|
|
|
|
|
|
|
|
|
| |
Such variables may immediately become nil or may have unpredictable
behavior.
Fixes <rdar://problem/12569201>.
llvm-svn: 170763
|
|
|
|
|
|
| |
which is wrong here.
llvm-svn: 170721
|
|
|
|
|
|
|
| |
category, when those properties will be implemented in category's
primary class or one of its super classes. // rdar://12568064
llvm-svn: 170573
|
|
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170500
|
|
|
|
|
|
|
|
| |
too). When instantiating a direct-initializer, if we find it has zero
arguments, produce an empty ParenListExpr rather than returning a null
expression.
llvm-svn: 170490
|
|
|
|
|
|
|
|
|
|
|
|
| |
copy-list-initialization (and doesn't add an additional copy step):
Fill in the ListInitialization bit when creating a CXXConstructExpr. Use it
when instantiating initializers in order to correctly handle instantiation of
copy-list-initialization. Teach TreeTransform that function arguments are
initializations, and so need this special treatment too. Finally, remove some
hacks which were working around SubstInitializer's shortcomings.
llvm-svn: 170489
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
per review discussion in r170365
This does limit these typedefs to being sequences, but no current usage
requires them to be contiguous (we could expand this to a more general
iterator pair range concept at some point).
Also, it'd be nice if SmallVector were constructible directly from an ArrayRef
but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the
inverse conversion. (& generalizing over all range-like things, while nice,
would require some nontrivial SFINAE I haven't thought about yet)
llvm-svn: 170482
|
|
|
|
|
|
| |
Add OpenCL images as clang builtin types.
llvm-svn: 170432
|
|
|
|
|
|
| |
these files to Windows style.
llvm-svn: 170431
|
|
|
|
| |
llvm-svn: 170428
|
|
|
|
|
|
|
|
| |
This fixes the storage class of extern decls that are merged with file level
statics. The patch also fixes the linkage computation so that they are
considered internal.
llvm-svn: 170406
|
|
|
|
|
|
|
|
| |
(This change only affects ObjC.)
<rdar://problem/12857117>.
llvm-svn: 170402
|
|
|
|
|
|
| |
missing 'void', insert a fixit to add the void.
llvm-svn: 170399
|
|
|
|
| |
llvm-svn: 170297
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes the missing warning here:
struct S {
template <typename T>
void meth() {
char arr[3];
arr[4] = 0; // warning: array index 4 is past the end of the array
}
};
template <typename T>
void func() {
char arr[3];
arr[4] = 0; // no warning
}
llvm-svn: 170180
|
|
|
|
|
|
| |
Sema::ActOnStartOfFunctionDef is already doing.
llvm-svn: 170179
|
|
|
|
|
|
| |
and make sure additional uses don't get introduced. <rdar://problem/12858424>.
llvm-svn: 170081
|
|
|
|
|
|
| |
to (SEL). Fixes // rdar://12859590
llvm-svn: 170058
|
|
|
|
|
|
| |
<rdar://problem/12857416>.
llvm-svn: 170056
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
implementation
has inconsistent ownership with the backing ivar, point the error location to the
ivar.
Pointing to the ivar (instead of the @synthesize) is better since this is where a fix is needed.
Also provide the location of @synthesize via a note.
This also fixes the problem where an auto-synthesized property would emit an error without
any location.
llvm-svn: 170039
|
|
|
|
|
|
|
|
|
|
| |
is switched of by about 0.8% (tested with int i<N>).
Additionally, this puts computing the diagnostic class into the hot
path more when parsing, in preparation for upcoming optimizations
in this area.
llvm-svn: 169976
|
|
|
|
|
|
| |
unavailable due to availability attributes. <rdar://problem/12798237>
llvm-svn: 169903
|