| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
| |
a typo:
t.c:1:7: error: invalid '==' at end of declaration; did you mean '='?
int x == 0;
^~
=
Implements rdar://8488464.
llvm-svn: 116035
|
|
|
|
|
|
| |
declarations. Fixes PR8169.
llvm-svn: 115411
|
|
|
|
|
|
|
|
|
|
| |
auto f(int) -> int
from Daniel Wallin!
(With a few minor bug fixes from me).
llvm-svn: 115322
|
|
|
|
| |
llvm-svn: 115004
|
|
|
|
|
|
| |
Fixes rdar://8476159.
llvm-svn: 114982
|
|
|
|
|
|
|
|
| |
verify that we aren't in a message-send expression before digging into
the identifier or looking ahead more tokens. Fixes a regression
(<rdar://problem/8483253>) I introduced with bracket insertion.
llvm-svn: 114968
|
|
|
|
|
|
| |
rdar://8483139.
llvm-svn: 114954
|
|
|
|
| |
llvm-svn: 114762
|
|
|
|
|
|
|
|
| |
Objective-C message sends. There is no functionality change here; this
is prep work for using the parameter types to help guide the
expression results when code-completing the argument.
llvm-svn: 114375
|
|
|
|
|
|
| |
errors. Improves code completion in yet another case.
llvm-svn: 114255
|
|
|
|
| |
llvm-svn: 114231
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of a binary expression, continue on and parse the right-hand side of
the binary expression anyway, but don't call the semantic actions to
type-check. Previously, we would see the error and then, effectively,
skip tokens until the end of the statement.
The result should be more useful recovery, both in the normal case
(we'll actually see errors beyond the first one in a statement), but
it also helps code completion do a much better job, because we do
"real" code completion on the right-hand side of an invalid binary
expression rather than completing with the recovery completion. For
example, given
x = p->y
if there is no variable named "x", we can still complete after the p->
as a member expression. Along the recovery path, we would have
completed after the "->" as if we were in an expression context, which
is mostly useless.
llvm-svn: 114225
|
|
|
|
|
|
| |
the enclosing scope, which confuses gcc v3.4 to no end
llvm-svn: 114174
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
missing the opening bracket '[', e.g.,
NSArray <CC>
at function scope. Previously, we would only give trivial completions
(const, volatile, etc.), because we're in a "declaration name"
scope. Now, we also provide completions for class methods of NSArray,
e.g.,
alloc
Note that we already had support for this after the first argument,
e.g.,
NSArray method:x <CC>
would get code completion for class methods of NSArray whose selector
starts with "method:". This was already present because we recover
as if NSArray method:x were a class message send missing the opening
bracket (which was committed in r114057).
llvm-svn: 114078
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
sends. These are far trickier than instance messages, because we
typically have something like
NSArray alloc]
where it appears to be a declaration of a variable named "alloc" up
until we see the ']' (or a ':'), and at that point we can't backtrace.
So, we use a combination of syntactic and semantic disambiguation to
treat this as a message send only when the type is an Objective-C type
and it has the syntax of a class message send (which would otherwise
be ill-formed).
llvm-svn: 114057
|
|
|
|
|
|
|
|
|
|
|
| |
narrow, almost useless case where we're inside a parenthesized
expression, e.g.,
(NSArray alloc])
The solution to the general case still eludes me.
llvm-svn: 114039
|
|
|
|
|
|
| |
from certain GCC's. Patch by Neil Vachharajani!
llvm-svn: 113995
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
'[' is missing. Prior commits improving recovery also improved code
completion beyond the first selector, e.g., at or after the "to" in
calculator add:x to:y
but not after "calculator". We now provide the same completions for
calculator <CC>
that we would for
[calculator <CC>
if "calculator" is an expression whose type is something that can
receive Objective-C messages.
This code completion works for instance and super message sends, but not
class message sends.
llvm-svn: 113976
|
|
|
|
|
|
|
|
| |
super method:arg]
will now recover nicely and insert the '[' before 'super'.
llvm-svn: 113971
|
|
|
|
|
|
| |
a getFoo]
llvm-svn: 113969
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
part of parser recovery. For example, given:
a method1:arg];
we detect after parsing the expression "a" that we have the start of a
message send expression. We pretend we've seen a '[' prior to the a,
then parse the remainder as a message send. We'll then give a
diagnostic+fix-it such as:
fixit-objc-message.m:17:3: error: missing '[' at start of message
send expression
a method1:arg];
^
[
The algorithm here is very simple, and always assumes that the open
bracket goes at the beginning of the message send. It also only works
for non-super instance message sends at this time.
llvm-svn: 113968
|
|
|
|
|
|
|
|
| |
expression, e.g., after the '(' that could also be a type cast. Here,
we provide types as code-completion results in C/Objective-C (C++
already had them), although we wouldn't in a normal expression context.
llvm-svn: 113904
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
instead"
This reverts commit r113631
Conflicts:
CMakeLists.txt
lib/CodeGen/CMakeLists.txt
llvm-svn: 113817
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
used in the default function argument as "used". Instead, when we
actually use the default argument, make another pass over the
expression to mark any used declarations as "used" at that point. This
addresses two kinds of related problems:
1) We were marking some declarations "used" that shouldn't be,
because we were marking them too eagerly.
2) We were failing to mark some declarations as "used" when we
should, if the first time it was instantiated happened to be an
unevaluated context, we wouldn't mark them again at a later point.
I've also added a potentially-handy visitor class template
EvaluatedExprVisitor, which only visits the potentially-evaluated
subexpressions of an expression. I bet this would have been useful for
noexcept...
Fixes PR5810 and PR8127.
llvm-svn: 113700
|
|
|
|
| |
llvm-svn: 113642
|
|
|
|
|
|
| |
of whatever we were using before...
llvm-svn: 113631
|
|
|
|
| |
llvm-svn: 113622
|
|
|
|
|
|
|
|
| |
spelled (#pragma, _Pragma, __pragma). In -E mode, use that information
to add appropriate newlines when translating _Pragma and __pragma into
#pragma, like GCC does. Fixes <rdar://problem/8412013>.
llvm-svn: 113553
|
|
|
|
|
|
|
|
| |
with comma-separated lists. We never actually used the comma
locations, nor did we store them in the AST, but we did manage to
waste time during template instantiation to produce fake locations.
llvm-svn: 113495
|
|
|
|
|
|
| |
libclang visitation.
llvm-svn: 113492
|
|
|
|
|
|
|
|
| |
typeid expressions:
- make sure we have a proper source location for the closing ')'
- cache the declaration of std::type_info once we've found it
llvm-svn: 113441
|
|
|
|
| |
llvm-svn: 113416
|
|
|
|
| |
llvm-svn: 113356
|
|
|
|
|
|
|
|
| |
CXXTemporaryObjectExpr, CXXScalarValueInitExpr, and
CXXUnresolvedConstructExpr, getting rid of a bunch of FIXMEs in the
process.
llvm-svn: 113319
|
|
|
|
|
|
| |
I, at least, make this typo all the time.
llvm-svn: 113243
|
|
|
|
|
|
| |
the end of a statement. Fixes <rdar://problem/6896493>.
llvm-svn: 113202
|
|
|
|
|
|
| |
enumeration definition. Fixes <rdar://problem/7159693>.
llvm-svn: 113201
|
|
|
|
|
|
| |
member initializers in a C++ constructor. Fixes <rdar://problem/7796492>.
llvm-svn: 113199
|
|
|
|
|
|
| |
Per Chris's comment.
llvm-svn: 112979
|
|
|
|
|
|
| |
c++ operator token. (radar 8328250).
llvm-svn: 112977
|
|
|
|
|
|
|
| |
"__attribute((pascal))" or "__pascal" (and "_pascal" under
-fborland-extensions). Support still needs to be added to llvm.
llvm-svn: 112939
|
|
|
|
|
|
|
| |
operators (and, or, etc.) to be used as selectors
to match g++'s behavior.
llvm-svn: 112935
|
|
|
|
| |
llvm-svn: 112905
|
|
|
|
|
|
| |
a "to match this {" note, pointing out the opener.
llvm-svn: 112709
|
|
|
|
| |
llvm-svn: 112577
|
|
|
|
| |
llvm-svn: 112566
|
|
|
|
|
|
| |
some issues being sorted out.
llvm-svn: 112493
|
|
|
|
|
|
|
|
|
|
| |
The extra data stored on user-defined literal Tokens is stored in extra
allocated memory, which is managed by the PreprocessorLexer because there isn't
a better place to put it that makes sure it gets deallocated, but only after
it's used up. My testing has shown no significant slowdown as a result, but
independent testing would be appreciated.
llvm-svn: 112458
|
|
|
|
|
|
| |
statement header (fixes radar 8295106).
llvm-svn: 112443
|
|
|
|
|
|
| |
a constructor.
llvm-svn: 112330
|