| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
It's not safe to blindly call getIdentifierInfo without checking the
token is not an annotation token.
llvm-svn: 225533
|
|
|
|
|
|
|
|
|
|
|
| |
Parser::ParseNamespace can get a little confused when it found itself
inside a compound statement inside of a non-static data member
initializer.
Try to determine that the statement expression's scope makes sense
before trying to parse it's contents.
llvm-svn: 225514
|
|
|
|
|
|
|
|
|
| |
Sema::CheckParmsForFunctionDef can't cope with a null TypeSourceInfo.
Don't let the AST contain the malformed lambda.
This fixes PR22122.
llvm-svn: 225505
|
|
|
|
|
|
|
| |
Weird constructs like __attribute__((inline)) or
__attibute__((typename)) should result in warnings, not errors.
llvm-svn: 225118
|
|
|
|
|
|
|
|
|
|
|
| |
This is a follow-up to r224915. This adds a bit more line noise to the tests
added in that revision to make sure the parser is ready for a toplevel decl
after each incorrect line. Use this to move the tests up to where they belong.
This uncovered that the early return was missing a call to
ActOnTagDefinitionError(), so add that. (Also fixes at least one of the crashes
on SLi's bot.)
llvm-svn: 224958
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r168626 added nicer diagnostics for attributes in the wrong places, such as
after the `final` on a class. To do this, it added code that did high-level
pattern matching for e.g. 'final' 'alignas' '(' and then skipped until the
closing ')'. If it saw that, it then went down the regular class parsing
path and then called MaybeParseCXX11Attributes() to parse the attribute after
the 'final' using real attribute parsing code. On invalid attributes, the
real attribute parsing code could eat more tokens than the pattern matching
code and for example skip past the '{' starting the class, which would then
lead to an assert. To prevent this, check for a good state after calling
MaybeParseCXX11Attributes() (which morphed into CheckMisplacedCXX11Attribute()
in r175575) and bail out if things look bleak.
Found by SLi's afl bot.
llvm-svn: 224915
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes this snippet from SLi's afl fuzzer output:
class {
i (x = <, enum
This parsed i as a function, x as a paramter, and the stuff after < as a
template list. This then called TryConsumeDeclarationSpecifier() which
called TryAnnotateCXXScopeToken() without checking the preconditions of
this function. Check them before calling, like all other callers of
TryAnnotateCXXScopeToken() do.
A more readable reproducer that causes the same crash is
class {
void i(int x = MyTemplateClass<int, union int>::foo());
};
The reduced version used an eof token as surprising token, but kw_int works
just as well to repro and is easier to insert into a test file.
llvm-svn: 224906
|
|
|
|
|
|
|
|
|
| |
isDeclarationSpecifier performs error recovers which jostles the token
stream. Specifically, TryAnnotateTypeOrScopeToken will end up consuming
a typename token which will confuse the attribute parsing machinery as
we no-longer have something identifier-like.
llvm-svn: 224903
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ParseCXXNonStaticMemberInitializer stashes away all the tokens for the
initializer and an additional EOF token to denote where the initializer
ends. However, it is possible for ParseLexedMemberInitializer to get
its hands on the "real" EOF token; since the two tokens are
indistinguishable, we end up consuming the EOF and descend into madness.
Instead, make it possible to tell which EOF token we are looking at.
This fixes PR21872.
llvm-svn: 224505
|
|
|
|
|
|
|
|
| |
So, place warning about property getter should not be used for side-effect
under its own group so warning can be turned off.
rdar://19137815
llvm-svn: 224479
|
|
|
|
|
|
|
|
|
| |
We would consume the lparen even if it wasn't followed by an identifier
or a star-identifier pair.
This fixes PR21815.
llvm-svn: 224403
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The parser can only be tricked into parsing a function template
definition by inserting a typename keyword before the function template
declaration. This used to make us crash, and now it's fixed.
While here, remove an unneeded boolean parameter from ParseDeclGroup.
This boolean always corresponded to non-typedef declarators at file
scope. ParseDeclGroup already has precise diagnostics for the function
definition typedef case, so we can let that through.
Fixes PR21839.
llvm-svn: 224287
|
|
|
|
|
|
|
|
|
| |
We would exit Sema::ActOnFinishSwitchStmt early if we didn't have a
body. This would leave an extra SwitchStmt on the SwitchStack.
This fixes PR21841.
llvm-svn: 224237
|
|
|
|
|
|
|
|
|
|
| |
Sema::handleAnnotateAttr expects that some basic validation is done on
the given AttributeList. However, ProcessAccessDeclAttributeList called
it directly. Instead, pass the list to ProcessDeclAttribute.
This fixes PR21847.
llvm-svn: 224204
|
|
|
|
|
|
|
|
|
| |
We would crash trying to treat a property member as a field. These
shoudl be forbidden anyway, reject programs which contain them.
This fixes PR21840.
llvm-svn: 224193
|
|
|
|
|
|
|
|
|
|
| |
While we would correctly handle asm("foo") and reject asm(L"bar"), we
weren't careful to handle cases where an ascii literal could be
concatenated with a wide literal.
This fixes PR21822.
llvm-svn: 223992
|
|
|
|
|
|
|
| |
but ignores module imports in debugger mode,
even inside functions.
llvm-svn: 223935
|
|
|
|
|
|
| |
MSVC parses and ignores these with a warning.
llvm-svn: 223413
|
|
|
|
|
|
| |
previously)
llvm-svn: 222832
|
|
|
|
| |
llvm-svn: 222665
|
|
|
|
|
|
| |
(This sometimes happens when a macro is used that expands to either the GNU noreturn attribute or _Noreturn.)
llvm-svn: 221630
|
|
|
|
| |
llvm-svn: 221582
|
|
|
|
|
|
| |
use a %select. Also ensure that nested namespace definitions are diagnosed properly. Both changes are motivated by post-commit feedback from r221580.
llvm-svn: 221581
|
|
|
|
| |
llvm-svn: 221580
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows 'namespace A::B { ... }' as a shorthand for 'namespace A {
namespace B { ... } }'. We already supported this correctly for error recovery;
promote that support to a full implementation.
This is not the right implementation: we do not maintain source fidelity
because we desugar the nested namespace definition in the parser. This is
tricky to avoid, since the definition genuinely does inject one named
entity per level in the namespace name.
llvm-svn: 221574
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a new form of expression of the form:
(expr op ... op expr)
where one of the exprs is a parameter pack. It expands into
(expr1 op (expr2onwards op ... op expr))
(and likewise if the pack is on the right). The non-pack operand can be
omitted; in that case, an empty pack gives a fallback value or an error,
depending on the operator.
llvm-svn: 221573
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Now that we have initial support for VSX, we can begin adding
intrinsics for programmer access to VSX instructions. This patch
performs the necessary enablement in the front end, and tests it by
implementing intrinsics for minimum and maximum using the vector
double data type.
The main change in the front end is to no longer disallow "vector" and
"double" in the same declaration (lib/Sema/DeclSpec.cpp), but "vector"
and "long double" must still be disallowed. The new intrinsics are
accessed via vec_max and vec_min with changes in
lib/Headers/altivec.h. Note that for v4f32, we already access
corresponding VMX builtins, but with VSX enabled we should use the
forms that allow all 64 vector registers.
The new built-ins are defined in include/clang/Basic/BuiltinsPPC.def.
I've added a new test in test/CodeGen/builtins-ppc-vsx.c that is
similar to, but much smaller than, builtins-ppc-altivec.c. This
allows us to test VSX IR generation without duplicating CHECK lines
for the existing bazillion Altivec tests.
Since vector double is now legal when VSX is available, I've modified
the error message, and changed where we test for it and for vector
long double, since the target machine isn't visible in the old place.
This serendipitously removed a not-pertinent warning about 'long'
being deprecated when used with 'vector', when "vector long double" is
encountered and we just want to issue an error. The existing tests
test/Parser/altivec.c and test/Parser/cxx-altivec.cpp have been
updated accordingly, and I've added test/Parser/vsx.c to verify that
"vector double" is now legitimate with VSX enabled.
There is a companion patch for LLVM.
llvm-svn: 220989
|
|
|
|
|
|
| |
we're in a new-type-id or conversion-type-id, since those things can legitimately be followed by a binary && operator.
llvm-svn: 220785
|
|
|
|
|
|
|
| |
overriding methods. Patch review by Richard Smith.
rdar://18295240
llvm-svn: 220703
|
|
|
|
|
|
|
|
| |
This is long-since overdue, and matches GCC 5.0. This should also be
backwards-compatible, because we already supported all of C11 as an extension
in C99 mode.
llvm-svn: 220244
|
|
|
|
|
|
|
|
| |
Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1).
Reviewed by Richard Smith
llvm-svn: 219589
|
|
|
|
| |
llvm-svn: 219043
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL has caused bootstrap failures on Linux and OSX buildbots running with -Werror.
Example report from http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/13183/steps/bootstrap%20clang/logs/stdio:
================================================================
[ 91%] Building CXX object tools/clang/tools/diagtool/CMakeFiles/diagtool.dir/ShowEnabledWarnings.cpp.o
In file included from /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/AMDGPUISelDAGToDAG.cpp:20:
In file included from /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/SIISelLowering.h:19:
/home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/SIInstrInfo.h:71:8: error: 'getLdStBaseRegImmOfs' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
bool getLdStBaseRegImmOfs(MachineInstr *LdSt,
^
/home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/include/llvm/Target/TargetInstrInfo.h:815:16: note: overridden virtual function is here
virtual bool getLdStBaseRegImmOfs(MachineInstr *LdSt,
^
================================================================
llvm-svn: 218969
|
|
|
|
|
|
|
|
|
|
|
|
| |
for an overriding method if class has at least one
'override' specified on one of its methods.
Reviewed by Doug Gregor. rdar://18295240
(I have already checked in all llvm files with missing 'override'
methods and Bob Wilson has fixed a TableGen of FastISel so
no warnings are expected from build of llvm after this patch.
I have already verified this).
llvm-svn: 218925
|
|
|
|
|
|
|
| |
Suggested by Richard Smith.
rdar://18508589.
llvm-svn: 218830
|
|
|
|
| |
llvm-svn: 218468
|
|
|
|
|
|
|
|
|
| |
lexer, add the token buffer underneath the caching lexer where possible and
push the tokens directly into the caching lexer otherwise. We previously
put the lexer into a corrupted state where we could not guarantee to provide
the tokens in the right order and would sometimes assert.
llvm-svn: 218333
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This fixes PR20023. In order to implement this scoping rule, we piggy
back on the existing LabelDecl machinery, by creating LabelDecl's that
will carry the "internal" name of the inline assembly label, which we
will rewrite the asm label to.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4589
llvm-svn: 218230
|
|
|
|
| |
llvm-svn: 217472
|
|
|
|
| |
llvm-svn: 217302
|
|
|
|
|
|
| |
contains an unmatched closing bracket token.
llvm-svn: 216518
|
|
|
|
| |
llvm-svn: 216485
|
|
|
|
|
|
|
|
| |
feature is c11 about nested struct declarations must have
struct-declarator-list. Without this change, code
which was meant for c99 breaks. rdar://18125536
llvm-svn: 216469
|
|
|
|
|
|
|
|
|
|
|
|
| |
__vector long is deprecated, but __vector long long is not. As a result, we
cannot check for __vector long (to issue the deprecation warning) as we parse
the type because we need to know how many 'long's we have first.
DeclSpec::Finish seems like a more-appropriate place to perform the check
(which places it with several other similar Altivec vector checks).
Fixes PR20720.
llvm-svn: 216342
|
|
|
|
|
|
|
|
|
|
| |
Fixes build for SPEC 2000 CPU. MSVC disables these aliases under /Za,
which enables stricter standards compliance. We don't currently have any
way to disable them.
Patch by Kevin Smith!
llvm-svn: 216270
|
|
|
|
|
|
| |
attributes parsing FIXMEs.
llvm-svn: 215814
|
|
|
|
|
|
| |
This fixes a regression I caused back in r211766.
llvm-svn: 215609
|
|
|
|
|
|
| |
declaration to our list of special cases.
llvm-svn: 215520
|
|
|
|
|
|
| |
location so their diagnostics have somewhere to point.
llvm-svn: 215416
|
|
|
|
|
|
|
|
|
|
|
| |
it. Diagnose with recovery if it appears after a function parameter that was
obviously supposed to be a parameter pack. Otherwise, warn if it immediately
follows a function parameter pack, because the user most likely didn't intend
to write a parameter pack followed by a C-style varargs ellipsis.
This warning can be syntactically disabled by using ", ..." instead of "...".
llvm-svn: 215408
|