| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
Sema::ActOnDocumentableDecls.
Patch by Robert Wilhelm.
llvm-svn: 185931
|
| |
|
|
|
|
| |
<rdar://problem/14354144>
llvm-svn: 185897
|
| |
|
|
|
|
| |
PR16561.
llvm-svn: 185887
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Combined with typo correction's new ability to apply global/absolute nested
name specifiers to possible corrections, cases such as in PR12287 where the
desired function is being shadowed by a lexically closer function with the
same name but a different number of parameters will now include a FixIt.
On a side note, since the test for this change caused
test/SemaCXX/typo-correction.cpp to exceed the typo correction limit for
a single file, I've included a test case for exceeding the limit and added
some comments to both the original and part two of typo-correction.cpp
warning future editors of the files about the limit.
llvm-svn: 185881
|
| |
|
|
| |
llvm-svn: 185880
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use UsualArithmeticConversions unconditionally in analysis of
comparisons and conditional operators: the method performs
the usual arithmetic conversions if both sides are arithmetic, and
usual unary conversions if they are not. This is just a cleanup
for conditional operators; for comparisons, it fixes the issue that
we would try to check isArithmetic() on an atomic type.
Also, fix GetExprRange() in SemaChecking.cpp so it deals with variables
of atomic type correctly.
Fixes PR15537.
llvm-svn: 185857
|
| |
|
|
|
|
| |
small size of the inner SmallVector.
llvm-svn: 185789
|
| |
|
|
| |
llvm-svn: 185787
|
| |
|
|
| |
llvm-svn: 185786
|
| |
|
|
| |
llvm-svn: 185785
|
| |
|
|
|
|
| |
specifying the vector size.
llvm-svn: 185784
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sema::MergeFunctionDecl attempts merging two decls even if the old decl
is invalid. This can lead to interesting circumstances where we
successfully merge the decls but the result makes no sense.
Take the following for example:
template <typename T>
int main(void);
int main(void);
Sema will not consider these to be overloads of the same name because
main can't be overloaded, which means that this must be a redeclaration.
In this case the templated decl is compatible with the non-templated
decl allowing the Sema::CheckFunctionDeclaration machinery to move on
and do bizarre things like setting the previous decl of a non-templated
decl to a templated decl!
The way I see it, we should just bail from MergeFunctionDecl if the old
decl is invalid.
This fixes PR16531.
llvm-svn: 185779
|
| |
|
|
|
|
| |
// rdar://14182680.
llvm-svn: 185762
|
| |
|
|
| |
llvm-svn: 185752
|
| |
|
|
|
|
|
|
|
|
| |
This boils down to us sending invalid function decls to
CheckFunctionDeclaration becauswe we did not consider that CheckMain
could cause the decl to be invalid. Instead, interogate the new decl's
main-validity and *then* send it over to get CheckFunctionDeclaration'd
if it was still valid after calling CheckMain.
llvm-svn: 185745
|
| |
|
|
| |
llvm-svn: 185715
|
| |
|
|
|
|
| |
abstract class type. // rdar://14261999
llvm-svn: 185710
|
| |
|
|
| |
llvm-svn: 185684
|
| |
|
|
|
|
| |
SmallVector size when creating iterators for the DenseMap.
llvm-svn: 185682
|
| |
|
|
| |
llvm-svn: 185611
|
| |
|
|
|
|
| |
avoid specifying the vector size unnecessarily.
llvm-svn: 185610
|
| |
|
|
|
|
|
|
|
| |
substitution failed, report that as a substitution failure rather than
pretending that there was no default argument.
The test cases in PR15673 have exposed some pre-existing poor diagnostics here.
llvm-svn: 185604
|
| |
|
|
| |
llvm-svn: 185602
|
| |
|
|
| |
llvm-svn: 185584
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR16456 reported that Clang implements a hybrid between AltiVec's
"Keyword and Predefine Method" and its "Context Sensitive Keyword
Method," where "bool" is always a keyword, but "vector" and "pixel"
are context-sensitive keywords. This isn't permitted by the AltiVec
spec. For consistency with gcc, this patch implements the Context
Sensitive Keyword Method for bool, and stops treating true and false
as keywords in Altivec mode.
The patch removes KEYALTIVEC as a trigger for defining these keywords
in include/clang/Basic/TokenKinds.def, and adds logic for "vector
bool" that mirrors the existing logic for "vector pixel." The test
case is taken from the bug report.
llvm-svn: 185580
|
| |
|
|
| |
llvm-svn: 185578
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The removal is tried by retrying the failed lookup of a correction
candidate with either the MemberContext or SS (CXXScopeSpecifier) or
both set to NULL if they weren't already. If the candidate identifier
is then looked up successfully, make a note in the candidate that the
SourceRange should include any existing nested name specifier even if
the candidate isn't adding a different one (i.e. the candidate has a
NULL NestedNameSpecifier).
Also tweak the diagnostic messages to differentiate between a suggestion
that just replaces the identifer but leaves the existing nested name
specifier intact and one that replaces the entire qualified identifier,
in cases where the suggested replacement is unqualified.
llvm-svn: 185487
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
NestedNameSpecifier.
CorrectTypo will now see and consider those corrections that are effectively
shadowed by other declarations in a closer context when resolved via an
unqualified lookup. This involves adding any parent namespaces to the set of
namespaces as fully-qualified name specifiers, and also adding potential
corrections that passed name lookup but were rejected by the given
CorrectionCandidateCallback into the set of failed corrections that should be
tried with the set of namespace specifiers.
llvm-svn: 185486
|
| |
|
|
| |
llvm-svn: 185446
|
| |
|
|
|
|
| |
with gcc.
llvm-svn: 185439
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Blocks, like lambdas, can be written in contexts which are required to be
treated as the same under ODR. Unlike lambdas, it isn't possible to actually
take the address of a block, so the mangling of the block itself doesn't
matter. However, objects like static variables inside a block do need to
be mangled in a consistent way.
There are basically three components here. One, block literals need a
consistent numbering. Two, objects/types inside a block literal need
to be mangled using it. Three, objects/types inside a block literal need
to have their linkage computed correctly.
llvm-svn: 185372
|
| |
|
|
| |
llvm-svn: 185305
|
| |
|
|
|
|
| |
InitListExpr.
llvm-svn: 185304
|
| |
|
|
|
|
|
|
|
| |
before the value computation of the result. In C, this is implied by there being
a sequence point after their evaluation, and in C++, it's implied by the
side-effects being sequenced before the expressions and statements in the
function body.
llvm-svn: 185282
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
standard's rule that an extern "C" declaration conflicts with any entity in the
global scope with the same name. Now we only care if the global scope entity is
a variable declaration (and so might have the same mangled name as the extern
"C" declaration). This has been reported as a standard defect.
Original commit message:
PR7927, PR16247: Reimplement handling of matching extern "C" declarations
across scopes.
When we declare an extern "C" name that is not a redeclaration of an entity in
the same scope, check whether it redeclares some extern "C" entity from another
scope, and if not, check whether it conflicts with a (non-extern-"C") entity in
the translation unit.
When we declare a name in the translation unit that is not a redeclaration,
check whether it conflicts with any extern "C" entities (possibly from other
scopes).
llvm-svn: 185281
|
| |
|
|
| |
llvm-svn: 185264
|
| |
|
|
| |
llvm-svn: 185256
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
across scopes.
When we declare an extern "C" name that is not a redeclaration of an entity in
the same scope, check whether it redeclares some extern "C" entity from another
scope, and if not, check whether it conflicts with a (non-extern-"C") entity in
the translation unit.
When we declare a name in the translation unit that is not a redeclaration,
check whether it conflicts with any extern "C" entities (possibly from other
scopes).
llvm-svn: 185229
|
| |
|
|
|
|
|
|
| |
Previously, for a field with an invalid in-class initializer, we
would create a CXXDefaultInitExpr referring to a null Expr*.
This is not a good idea.
llvm-svn: 185216
|
| |
|
|
| |
llvm-svn: 185215
|
| |
|
|
|
|
|
|
|
| |
This replaces a long list of declarations for visitor functions with
a list generated from DeclNodes.inc. Nothing really interesting came
out of it; we had comprehensive coverage anyway
(excluding FriendTemplateDecls).
llvm-svn: 185118
|
| |
|
|
|
|
| |
initialized during aggregate initialization of the surrounding structure.
llvm-svn: 185117
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
passing arguments in the fixed style.
We have an abstraction for deciding this, but it's (1) deep in
IR-generation, (2) necessarily tied to exact argument lists, and
(3) triggered by unprototyped function types, which we can't
legitimately make in C++ mode. So this solution, wherein Sema
rewrites the function type to an exact prototype but leaves the
variadic bit enabled so as to request x86-64-like platforms to
pass the extra variadic info, is very much a hack, but it's one
that works in practice on the platforms that LLDB will support
in the medium term --- the only place we know of where it's a
problem is instance methods in Windows, where variadic functions
are implicitly cdecl. We may have a more abstracted base on which
to build a solution by then.
rdar://13731520
llvm-svn: 185112
|
| |
|
|
| |
llvm-svn: 185108
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
tag with that name in an enclosing scope.
r177473 made us correctly consider only those declarations in the
enclosing namespace scope when looking for a friend declaration. Under
ms-extensions mode, where we do some level of friend injection, this
meant that we were introducing a new tag type into a different scope
than what Microsoft actually does. Address this by only doing the
friend injection when we didn't see any tag with that name in any
outer scope. Fixes <rdar://problem/14250378>.
llvm-svn: 185100
|
| |
|
|
| |
llvm-svn: 185058
|
| |
|
|
|
|
| |
specifically states that the type is incomplete and points to the forward declaration of the incomplete type.
llvm-svn: 185056
|
| |
|
|
| |
llvm-svn: 185053
|
| |
|
|
|
|
|
|
| |
side-effect is not sequenced before its value computation. Also fix a
mishandling of ?: expressions where the condition is constant that was
exposed by the tests for this.
llvm-svn: 185035
|
| |
|
|
|
|
|
| |
private ivars in class extensions and class
@implementation. // rdar://14278560
llvm-svn: 185025
|