| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The lowering looks a lot like normal EH lowering, with the exception
that the exceptions are caught by executing filter expression code
instead of matching typeinfo globals. The filter expressions are
outlined into functions which are used in landingpad clauses where
typeinfo would normally go.
Major aspects that still need work:
- Non-call exceptions in __try bodies won't work yet. The plan is to
outline the __try block in the frontend to keep things simple.
- Filter expressions cannot use local variables until capturing is
implemented.
- __finally blocks will not run after exceptions. Fixing this requires
work in the LLVM SEH preparation pass.
The IR lowering looks like this:
// C code:
bool safe_div(int n, int d, int *r) {
__try {
*r = normal_div(n, d);
} __except(_exception_code() == EXCEPTION_INT_DIVIDE_BY_ZERO) {
return false;
}
return true;
}
; LLVM IR:
define i32 @filter(i8* %e, i8* %fp) {
%ehptrs = bitcast i8* %e to i32**
%ehrec = load i32** %ehptrs
%code = load i32* %ehrec
%matches = icmp eq i32 %code, i32 u0xC0000094
%matches.i32 = zext i1 %matches to i32
ret i32 %matches.i32
}
define i1 zeroext @safe_div(i32 %n, i32 %d, i32* %r) {
%rr = invoke i32 @normal_div(i32 %n, i32 %d)
to label %normal unwind to label %lpad
normal:
store i32 %rr, i32* %r
ret i1 1
lpad:
%ehvals = landingpad {i8*, i32} personality i32 (...)* @__C_specific_handler
catch i8* bitcast (i32 (i8*, i8*)* @filter to i8*)
%ehptr = extractvalue {i8*, i32} %ehvals, i32 0
%sel = extractvalue {i8*, i32} %ehvals, i32 1
%filter_sel = call i32 @llvm.eh.seh.typeid.for(i8* bitcast (i32 (i8*, i8*)* @filter to i8*))
%matches = icmp eq i32 %sel, %filter_sel
br i1 %matches, label %eh.except, label %eh.resume
eh.except:
ret i1 false
eh.resume:
resume
}
Reviewers: rjmccall, rsmith, majnemer
Differential Revision: http://reviews.llvm.org/D5607
llvm-svn: 226760
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The improved completion in call context now works with:
- Functions.
- Member functions.
- Constructors.
- New expressions.
- Function call expressions.
- Template variants of the previous.
There are still rough edges to be fixed:
- Provide support for optional parameters. (fix known)
- Provide support for member initializers. (fix known)
- Provide support for variadic template functions. (fix unknown)
- Others?
llvm-svn: 226670
|
| |
|
|
| |
llvm-svn: 226363
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch add a new option to dis-allow all inline asm.
Any GCC style inline asm will be reported as an error.
Reviewers: rnk, echristo
Reviewed By: rnk, echristo
Subscribers: bob.wilson, rnk, echristo, rsmith, cfe-commits
Differential Revision: http://reviews.llvm.org/D6870
llvm-svn: 226340
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ambiguity but wasn't.
In the new test case, "click" wasn't being corrected properly because
Sema::ClassifyName would call CorrectTypo for "click" then later
Sema::DiagnoseEmptyLookup would call CorrectTypoDelayed for the same use
of "click" (the former by the parser needing to determine what the
identifier is so it knows how to parse the statement, i.e. is it the
beginning of a declaration or an expression). CorrectTypo would record
that typo correction for "click" failed and CorrectTypoDelayed would see
that and not even try to correct the typo, even though in this case
CorrectTypo failed due to an ambiguity (both "Click" and "clock" having
an edit distance of one from "click") that could be resolved with more
information. The fix is two-fold:
1) Have CorrectTypo not record failed corrections if the reason for
the failure was two or more corrections with the same edit
distance, and
2) Make the CorrectionCandidateCallback used by
Parser::ParseCastExpression reject FunctionDecl candidates when the
next token after the identifier is a ".", "=", or "->" since
functions cannot be assigned to and do not have members that can be
referenced.
The reason for two correction spots is that from r222549 until r224375
landed, the first correction attempt would fail completely but the
second would suggest "clock" while having the note point to the
declaration of "Click".
llvm-svn: 226334
|
| |
|
|
| |
llvm-svn: 226307
|
| |
|
|
|
|
|
|
|
|
|
| |
There was already an explicit check for that for the first decl. Move that
to a different place so that it's called for the following decls too. Also
don't randomly set the BitfieldSize ExprResult to true (this sets a pointer to
true internally).
Found by SLi's bot.
llvm-svn: 226306
|
| |
|
|
| |
llvm-svn: 226067
|
| |
|
|
|
|
|
|
|
|
| |
Sorry for the noise, I managed to miss a bunch of recent regressions of
include orderings here. This should actually sort all the includes for
Clang. Again, no functionality changed, this is just a mechanical
cleanup that I try to run periodically to keep the #include lines as
regular as possible across the project.
llvm-svn: 225979
|
| |
|
|
|
|
|
|
|
| |
The EOF token injection technique is preferable to using
isBeforeInTranslationUnit to determine whether or not additional cleanup
is needed. I don't have an example off-hand that requires it but it is
nicer nonetheless.
llvm-svn: 225776
|
| |
|
|
| |
llvm-svn: 225768
|
| |
|
|
|
|
|
|
| |
Mark the end of the method body with an EOF token, collect it once we
expect to be done with method body parsing. No functionality change
intended.
llvm-svn: 225765
|
| |
|
|
|
|
|
| |
No functionality change intended, just moving code around to make it
simpler.
llvm-svn: 225763
|
| |
|
|
|
|
| |
the tokens around so we can diagnose an error rather than silently discarding them.
llvm-svn: 225755
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
to the Alitivec support in clang. __bool is functionally identical to using bool when declaring vector types. For example:
vector bool char v_bc;
vector __bool char v___bc;
clang already supported vector/__vector and pixel/__pixel but was missing __bool.
http://llvm.org/bugs/show_bug.cgi?id=19220
For reference: https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/PowerPC-AltiVec_002fVSX-Built-in-Functions.html
http://reviews.llvm.org/D6882
llvm-svn: 225664
|
| |
|
|
|
|
|
|
| |
Similar to r225619, use a special EOF token to mark the end of the
exception specification instead of cxx_exceptspec_end. Use the current
scope as the marker.
llvm-svn: 225622
|
| |
|
|
|
|
| |
No functional change intended, just tidy up the parse flow.
llvm-svn: 225620
|
| |
|
|
|
|
|
| |
I added setEofData/getEofData to solve this sort of problem back in
r224505. Use the Param's decl to tell us if this is *our* EOF token.
llvm-svn: 225619
|
| |
|
|
| |
llvm-svn: 225616
|
| |
|
|
|
|
|
|
| |
It is not correct to let it consume the cxx_defaultarg_end token. I'm
starting to wonder if it makes more sense to stop SkipUntil from
consuming such tokens.
llvm-svn: 225615
|
| |
|
|
|
|
|
|
| |
Recovery from malformed lambda introducers would find us consuming the
synthetic default argument token, which is bad. Instead, stop right
before that token.
llvm-svn: 225613
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 225129
|
| |
|
|
| |
llvm-svn: 225122
|
| |
|
|
|
|
|
| |
Weird constructs like __attribute__((inline)) or
__attibute__((typename)) should result in warnings, not errors.
llvm-svn: 225118
|
| |
|
|
|
|
| |
That's what I get for last second changes...
llvm-svn: 224967
|
| |
|
|
|
|
|
| |
Instead of crashing, recover by eating the extra trailing scope
qualifier. This means we will treat 'struct A:: {' as 'struct A {'.
llvm-svn: 224966
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Let's pretend that we didn't see the '::' instead of go on believing
that we've got some anonymous, but globally qualified, struct.
llvm-svn: 224945
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
Clang has a hack to accept definitions of structs with tag names which
have the same name as intrinsics. However, this hack didn't guard
against annotation tokens showing up in the token stream.
llvm-svn: 224909
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 224893
|
| |
|
|
|
|
| |
the statement attributes (as per the standard), and function-try-blocks may not have attributes. NFC.
llvm-svn: 224662
|
| |
|
|
|
|
| |
when we diagnose this as an error.
llvm-svn: 224595
|
| |
|
|
| |
llvm-svn: 224562
|
| |
|
|
|
|
| |
declared return type (including a trailing-return-type in C++14).
llvm-svn: 224561
|
| |
|
|
|
|
| |
Fixes PR21947.
llvm-svn: 224558
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 224434
|
| |
|
|
|
|
|
|
|
| |
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 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
|
| |
|
|
|
|
|
|
| |
expressions because the lookup finds a different name than the original, fixed by updating the LookupResult's name with the name of the found decl. Second is that we also diagnose delayed typo exprs in the index of an array subscript expression.
The testcase shows a third bug with a FIXME in it.
llvm-svn: 224183
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in debugger mode) to accept @import declarations
and pass them to the debugger.
In the preprocessor, accept import declarations
if the debugger is enabled, but don't actually
load the module, just pass the import path on to
the preprocessor callbacks.
In the Objective-C parser, if it sees an import
declaration in statement context (usual for LLDB),
ignore it and return a NullStmt.
llvm-svn: 223855
|
| |
|
|
|
|
| |
MSVC parses and ignores these with a warning.
llvm-svn: 223413
|