| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
and rapidly becoming untrue.
llvm-svn: 150165
|
| |
|
|
| |
llvm-svn: 150129
|
| |
|
|
| |
llvm-svn: 150126
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
value of class type, look for a unique conversion operator converting to
integral or unscoped enumeration type and use that. Implements [expr.const]p5.
Sema::VerifyIntegerConstantExpression now performs the conversion and returns
the converted result. Some important callers of Expr::isIntegralConstantExpr
have been switched over to using it (including all of those required for C++11
conformance); this switch brings a side-benefit of improved diagnostics and, in
several cases, simpler code. However, some language extensions and attributes
have not been moved across and will not perform implicit conversions on
constant expressions of literal class type where an ICE is required.
In passing, fix static_assert to perform a contextual conversion to bool on its
argument.
llvm-svn: 149776
|
| |
|
|
|
|
| |
expressions and block literals. As it turns out, almost all the logic can be shared.
llvm-svn: 149031
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function body. This keeps the brace count accurate to prevent
additional errors. Also, moved the caret from the brace to the function
name.
Code:
class F{ int Foo{ return 1; } };
Fixed error:
parameters.cc:1:14: error: function definition does not declare parameters
class F{ int Foo{ return 1; } };
^
1 error generated.
Old errors:
parameters.cc:1:17: error: function definition does not declare parameters
class F{ int Foo{ return 1; } };
^
parameters.cc:1:30: error: expected ';' after class
class F{ int Foo{ return 1; } };
^
;
parameters.cc:1:31: error: expected external declaration
class F{ int Foo{ return 1; } };
^
3 errors generated.
llvm-svn: 148621
|
| |
|
|
|
|
| |
Fixes PR6484. Patch from Jason Switzer!
llvm-svn: 148270
|
| |
|
|
|
|
| |
complicated, but we have to be careful about when exactly captures are marked given PotentiallyPotentiallyEvaluated contexts. (Actually, it's not 100% correct yet, but it's close enough for the moment.)
llvm-svn: 147723
|
| |
|
|
|
|
| |
pieces to build the lambda class and its call operator. Create an actual scope for the lambda body.
llvm-svn: 147595
|
| |
|
|
|
|
| |
use it. Unconditionally error on lambda expressions because they don't work in any meaningful way yet.
llvm-svn: 147515
|
| |
|
|
|
|
|
| |
'is an extension'. The former is inappropriate and confusing when building with
-Werror/-pedantic-errors.
llvm-svn: 147357
|
| |
|
|
|
|
|
| |
This works like described in http://drdobbs.com/blogs/cpp/231602010
Fixes http://llvm.org/PR11609
llvm-svn: 147202
|
| |
|
|
|
|
|
|
| |
reasonable-looking but ill-formed for-range statement of the form:
for (expression : expression)
llvm-svn: 147006
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stopping at '@' was originally intended to avoid skipping an '@' at the @interface context
when doing parser recovery, but we should not stop at all '@' tokens because they may be part
of expressions (e.g. in @"string", @selector(), etc.), so in most cases we will want to skip them.
This commit caused 'test/Parser/method-def-in-class.m' to fail for the cases where we tried to
recover from unmatched angle bracket but IMO it is not a big deal to not have good recovery
from such broken code and the way we did recovery would not always work anyway (e.g. if there was '@'
in an expression).
The case that rdar://7029784 is about still passes.
llvm-svn: 146815
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
diagnostic message are compared. If either is a substring of the other, then
no error is given. This gives rise to an unexpected case:
// expect-error{{candidate function has different number of parameters}}
will match the following error messages from Clang:
candidate function has different number of parameters (expected 1 but has 2)
candidate function has different number of parameters
It will also match these other error messages:
candidate function
function has different number of parameters
number of parameters
This patch will change so that the verification string must be a substring of
the diagnostic message before accepting. Also, all the failing tests from this
change have been corrected. Some stats from this cleanup:
87 - removed extra spaces around verification strings
70 - wording updates to diagnostics
40 - extra leading or trailing characters (typos, unmatched parens or quotes)
35 - diagnostic level was included (error:, warning:, or note:)
18 - flag name put in the warning (-Wprotocol)
llvm-svn: 146619
|
| |
|
|
|
|
| |
in classes. // rdar://10535349
llvm-svn: 146504
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Necessary to parse Microsoft ATL code.
Example:
int array[] = {
0,
__if_exists(CLASS::Type) {2, }
3
};
will declare an array of 2 or 3 elements depending on if CLASS::Type exists or not.
llvm-svn: 146447
|
| |
|
|
|
|
| |
// rdar://10095131
llvm-svn: 146304
|
| |
|
|
| |
llvm-svn: 146147
|
| |
|
|
|
|
| |
Fixes PR2709.
llvm-svn: 145928
|
| |
|
|
|
|
| |
<rdar://problem/10465079>.
llvm-svn: 145656
|
| |
|
|
|
|
| |
class) since members are public by default.
llvm-svn: 145580
|
| |
|
|
|
|
| |
class scope.
llvm-svn: 144980
|
| |
|
|
|
|
| |
defaulted or deleted.
llvm-svn: 144270
|
| |
|
|
|
|
|
|
|
| |
instead of a semicolon (as sometimes happens during refactorings). When such a
comma is seen at the end of a line, and is followed by something which can't
possibly be a declarator (or even something which might be a plausible typo for
a declarator), suggest that a semicolon was intended.
llvm-svn: 142544
|
| |
|
|
|
|
| |
of an attrib is missing. gcc does not allow the closing parenthesis to be omitted.
llvm-svn: 142255
|
| |
|
|
| |
llvm-svn: 142053
|
| |
|
|
| |
llvm-svn: 142050
|
| |
|
|
|
|
| |
-std=c++0x. Patch by Ahmed Charles!
llvm-svn: 141900
|
| |
|
|
|
|
| |
attributes are found, propagate them to subsequent declarations.
llvm-svn: 141861
|
| |
|
|
|
|
| |
colon after access specifiers in C++
llvm-svn: 141852
|
| |
|
|
|
|
|
|
| |
We'd also like for "C++11" or "c++11" to be used for the warning
groups, but without removing the old warning flags. Patches welcome;
I've run out of time to work on this today.
llvm-svn: 141801
|
| |
|
|
|
|
|
| |
delimiter pairs and detect when we exceed the implementation limit for
nesting depth, from Aaron Ballman!
llvm-svn: 141782
|
| |
|
|
|
|
|
|
|
| |
which enables support for C99 storage-class specifiers.
This extension is intended to be used by implementations to implement
OpenCL C built-in functions.
llvm-svn: 141271
|
| |
|
|
| |
llvm-svn: 141270
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
increasingly prevailing case to the point that new features
like ARC don't even support the fragile ABI anymore.
This required a little bit of reshuffling with exceptions
because a check was assuming that ObjCNonFragileABI was
only being set in ObjC mode, and that's actually a bit
obnoxious to do.
Most, though, it involved a perl script to translate a ton
of test cases.
Mostly no functionality change for driver users, although
there are corner cases with disabling language-specific
exceptions that we should handle more correctly now.
llvm-svn: 140957
|
| |
|
|
|
|
| |
on declarators written as types.
llvm-svn: 140931
|
| |
|
|
|
|
| |
error recovery in both dialects. This should fix the GCC test suite failures as well.
llvm-svn: 140847
|
| |
|
|
|
|
| |
and handle asm comments using semicolons correctly. (The comments are actually surprisingly tricky.)
llvm-svn: 140837
|
| |
|
|
| |
llvm-svn: 140802
|
| |
|
|
|
|
|
| |
support for the C++0x draft [[align]] attribute and add the C1X
standard header file stdalign.h
llvm-svn: 140796
|
| |
|
|
|
|
| |
attribute-specifiers
llvm-svn: 140794
|
| |
|
|
|
|
| |
end of a decl-specifier-seq
llvm-svn: 140793
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The token stream was not getting properly reset when leaving
ParseLexedMethodDef in some error cases. In the testcase, that caused later
accesses to the token stream to touch memory which had been freed as we
finished parsing the class definition. Major hat-tip to AddressSanitizer for
helping pinpoint the use-after-free, including the allocation and deallocation
points:
==21510== ERROR: AddressSanitizer heap-use-after-free on address 0x7feb3de87848 at pc 0x249f4e2 bp 0x7fff15a89df0 sp 0x7fff15a89ce0
READ of size 1 at 0x7feb3de87848 thread T0
#0 0x249f4e2 clang::TokenLexer::Lex()
#1 0x1c834a0 clang::Parser::ConsumeToken()
#2 0x1c7dc0f clang::Parser::ParseDeclarationOrFunctionDefinition()
#3 0x1c7e16b clang::Parser::ParseDeclarationOrFunctionDefinition()
<snip>
0x7feb3de87848 is located 1992 bytes inside of 3816-byte region [0x7feb3de87080,0x7feb3de87f68)
freed by thread T0 here:
#0 0x3a22c19 free
#1 0x1d136a1 clang::Parser::LexedMethod::~LexedMethod()
#2 0x1cef528 clang::Parser::DeallocateParsedClasses()
#3 0x1cef676 clang::Parser::PopParsingClass()
#4 0x1cea094 clang::Parser::ParseCXXMemberSpecification()
#5 0x1ce7ae5 clang::Parser::ParseClassSpecifier()
#6 0x1cfe588 clang::Parser::ParseDeclarationSpecifiers()
#7 0x1c7dbe8 clang::Parser::ParseDeclarationOrFunctionDefinition()
#8 0x1c7e16b clang::Parser::ParseDeclarationOrFunctionDefinition()
<snip>
previously allocated by thread T0 here:
#0 0x3a2302d realloc
#1 0x39d7c97 llvm::SmallVectorBase::grow_pod()
#2 0x1ac588e llvm::SmallVectorImpl<>::push_back()
#3 0x1d12d8b clang::Parser::ConsumeAndStoreUntil()
#4 0x1c9c24d clang::Parser::ConsumeAndStoreUntil()
#5 0x1d12c1e clang::Parser::ConsumeAndStoreUntil()
#6 0x1c9c24d clang::Parser::ConsumeAndStoreUntil()
#7 0x1d10042 clang::Parser::ParseCXXInlineMethodDef()
#8 0x1cec51a clang::Parser::ParseCXXClassMemberDeclaration()
#9 0x1ce9de5 clang::Parser::ParseCXXMemberSpecification()
#10 0x1ce7ae5 clang::Parser::ParseClassSpecifier()
#11 0x1cfe588 clang::Parser::ParseDeclarationSpecifiers()
#12 0x1c7dbe8 clang::Parser::ParseDeclarationOrFunctionDefinition()
#13 0x1c7e16b clang::Parser::ParseDeclarationOrFunctionDefinition()
<snip>
llvm-svn: 140427
|
| |
|
|
|
|
|
|
|
|
| |
reentering the delayed function context correctly. The problem was that all template params were reintroduced inside the same scope. So if we had a situation where we had 2 template params with the same name at different scope then clang would generate an error about ambiguous name.
The solution is to create a new ParseScope(Scope::TemplateParamScope) for each template scope that we want to reenter. (from the outmost to the innermost scope)
This fixes some errors when parsing MFC code with clang.
llvm-svn: 140344
|
| |
|
|
|
|
|
| |
erronously trigger the digraph correction fix-it. Include a new test to catch
this in the future.
llvm-svn: 140175
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For instance:
template <class T> void E() {};
class F {};
void test() {
::E<::F>();
E<::F>();
}
Gives the following error messages:
error: found '<::' after a template name which forms the
digraph '<:' (aka '[') and a ':', did you mean '< ::'?
::E<::F>();
^~~
< ::
error: expected expression
E<::F>();
^
error: expected ']'
note: to match this '['
E<::F>();
This patch adds the digraph fix-it check right before the name lookup,
moves the shared checking code to a new function, and adds new
tests to catch future regressions.
llvm-svn: 140039
|
| |
|
|
|
|
|
|
|
| |
collision between C99 hexfloats and C++0x user-defined literals by
giving C99 hexfloats precedence. Also, warning about user-defined
literals that conflict with hexfloats and those that have names that
are reserved by the implementation. Fixes <rdar://problem/9940194>.
llvm-svn: 138839
|
| |
|
|
|
|
| |
Patch by Chris Cudmore!
llvm-svn: 138533
|
| |
|
|
|
|
|
| |
entirely use the existing -Wunused-value infrastructure. This also fixes
a few missed cases for -Wunused in general.
llvm-svn: 137916
|