loop and switch statements, by teaching Scope that a function scope never has
a continue/break parent for the purposes of control flow. Remove the hack in
block and lambda expressions which worked around this by pretending that such
expressions were continue/break scopes.
Remove Scope::ControlParent, since it's unused.
In passing, teach default statements to recover properly from a missing ';', and
add a fixit for same to both default and case labels (the latter already
recovered correctly).
llvm-svn: 150776
default is '=', and reword the warning about explicitly capturing
'this' in such lambdas to indicate that only explicit capture is
banned.
Introduce Fix-Its for this and other "save the programmer from
themself" rules regarding what can be explicitly captured and what
must be implicitly captured.
llvm-svn: 150256
o Correct the handling of the restrictions on usage of cv-qualified and
ref-qualified function types.
o Fix a bug where such types were rejected in template type parameter default
arguments, due to such arguments not being treated as a template type arg
context.
o Remove the ExtWarn for usage of such types as template arguments; that was
a standard defect, not a GCC extension.
o Improve the wording and unify the code for diagnosing cv-qualifiers with the
code for diagnosing ref-qualifiers.
llvm-svn: 150244
-fixit-recompile
applies fixits and recompiles the result
-fixit-to-temporary
applies fixits to temporary files
-fix-only-warnings">,
applies fixits for warnings only, not errors
Combining "-fixit-recompile -fixit-to-temporary" allows testing the result of fixits
without touching the original sources.
llvm-svn: 149027
Old error:
plusequaldeclare1.cc:3:8: error: expected ';' at end of declaration
int x += 6;
^
;
New error:
plusequaldeclare1.cc:3:9: error: invalid '+=' at end of declaration; did you
mean '='?
int x += 6;
^~
=
llvm-svn: 148433
- If the declarator is at the start of a line, and the previous line contained
another declarator and ended with a comma, then that comma was probably a
typo for a semicolon:
int n = 0, m = 1, l = 2, // k = 5;
myImportantFunctionCall(); // oops!
- If removing the parentheses would correctly initialize the object, then
produce a note suggesting that fix.
- Otherwise, if there is a simple initializer we can suggest which performs
value-initialization, then provide a note suggesting a correction to that
initializer.
Sema::Declarator now tracks the location of the comma prior to the declarator in
the declaration, if there is one, to facilitate providing the note. The code to
determine an appropriate initializer from the -Wuninitialized warning has been
factored out to allow use in both that and -Wvexing-parse.
llvm-svn: 148072
- reject definitions of enums within friend declarations
- require 'enum', not 'enum class', for non-declaring references to scoped
enumerations
llvm-svn: 147824
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
declaration tickles a bug in the way we handle visibility pragmas.
The improvement to error recovery for template function definitions declared
with the 'typedef' specifier in r145372 is unrelated and not reverted here.
llvm-svn: 145541
declaration at namespace scope is followed by a semicolon and an open-brace
(or in C++, a 'try', ':' or '='), then the error is probably a function
definition with a spurious ';', rather than a mysterious '{'.
llvm-svn: 145372
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
and DefaultFunctionArrayLvalueConversion. To prevent
significant regression for should-this-be-a-call fixits,
and to repair some such regression from the introduction of
bound member placeholders, make those placeholder checks
try to build calls appropriately. Harden the build-a-call
logic while we're at it.
llvm-svn: 141738
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
We had an extension which allowed const static class members of floating-point type to have in-class initializers, 'as a C++0x extension'. However, C++0x does not allow this. The extension has been kept, and extended to all literal types in C++0x mode (with a fixit to add the 'constexpr' specifier).
llvm-svn: 140801
RUN: foo
RUN: bar || true
is equivalent to:
RUN: foo && bar || true
which is equivalent to:
RUN: (foo && bar) || true
This resulted in several of the fixit tests not really testing anything.
llvm-svn: 139132
Change TypoCorrection to store a set of NamedDecls instead of a single
NamedDecl. Also add initial support for performing function overload
resolution to Sema::DiagnoseEmptyLookup.
llvm-svn: 136807
appropriate sentinel at the end of the argument list. Also, put the
sentinel warnings under -Wsentinel. Fixes <rdar://problem/8764236>.
llvm-svn: 136566
vector<int>
to
std::vector<int>
Patch by Kaelyn Uhrain, with minor tweaks + PCH support from me. Fixes
PR5776/<rdar://problem/8652971>.
Thanks Kaelyn!
llvm-svn: 134007
in the classification of template names and using declarations. We now
properly typo-correct the leading identifiers in statements to types,
templates, values, etc. As an added bonus, this reduces the number of
lookups required for disambiguation.
llvm-svn: 130288
looking at the context and the correction and using a custom
diagnostic. Also, enable some Fix-It tests that were somewhat lamely
disabled.
llvm-svn: 130283
performs name lookup for an identifier and resolves it to a
type/expression/template/etc. in the same step. This scheme is
intended to improve both performance (by reducing the number of
redundant name lookups for a given identifier token) and error
recovery (by giving Sema a chance to correct type names before the
parser has decided that the identifier isn't a type name). For
example, this allows us to properly typo-correct type names at the
beginning of a statement:
t.c:6:3: error: use of undeclared identifier 'integer'; did you mean
'Integer'?
integer *i = 0;
^~~~~~~
Integer
t.c:1:13: note: 'Integer' declared here
typedef int Integer;
^
Previously, we wouldn't give a Fix-It because the typo correction
occurred after the parser had checked whether "integer" was a type
name (via Sema::getTypeName(), which isn't allowed to typo-correct)
and therefore decided to parse "integer * i = 0" as an expression. By
typo-correcting earlier, we typo-correct to the type name Integer and
parse this as a declaration.
Moreover, in this context, we can also typo-correct identifiers to
keywords, e.g.,
t.c:7:3: error: use of undeclared identifier 'vid'; did you mean
'void'?
vid *p = i;
^~~
void
and recover appropriately.
Note that this is very much a work-in-progress. The new
Sema::ClassifyName is only used for expression-or-declaration
disambiguation in C at the statement level. The next steps will be to
make this work for the same disambiguation in C++ (where
functional-style casts make some trouble), then push it
further into the parser to eliminate more redundant name lookups.
Fixes <rdar://problem/7963833> for C and starts us down the path of
<rdar://problem/8172000>.
llvm-svn: 130082
typo. This can happen with context-sensitive keywords like "super",
when typo correction didn't know that "super" wasn't permitted in this
context.
llvm-svn: 117372
we did was an acceptable lookup. If it is, then we can re-use that
lookup result. If it isn't, we have to perform the lookup again. This
is almost surely the cause behind the mysterious typo.m failures on
some builders; we were getting the wrong lookup results returned.
llvm-svn: 116586
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
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
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
a simple, quick check to determine whether the expression starting
with '[' can only be an Objective-C message send. If so, don't parse
it as an array subscript expression. This improves recovery for, e.g.,
[a method1]
[a method2]
so that we now produce
t.m:10:13: error: expected ';' after expression
[a method]
^
instead of some mess about expecting ']'.
llvm-svn: 105221
non-function-local declarations with names similar to what the user
typed. For example, this allows us to correct 'supper' to 'super' in
an Objective-C message send, even though the C function 'isupper' has
the same edit distance.
llvm-svn: 104023
consider "super" as a candidate whenever we're parsing an expression
within an Objective-C method in an interface that has a superclass. At
some point, we'd like to give "super" a little edge over non-local
names; that will come later.
llvm-svn: 104022
look from an Objective-C class or category to its implementation, to
pick up synthesized ivars. Fixes a problem reported by David
Chisnall.
llvm-svn: 101792
generally recover from typos in keywords (since we would effectively
have to mangle the token stream). However, there are still benefits to
typo-correcting with keywords:
- We don't make stupid suggestions when the user typed something
that is similar to a keyword.
- We can suggest the keyword in a diagnostic (did you mean
"static_cast"?), even if we can't recover and therefore don't have
a fix-it.
llvm-svn: 101274
receiver is a mis-typed class name. Previously, we would give a non-specific
typo-correction diagnostic from the expression-parsing code, but there
was no fix-it because it was too late to recover. Now, we give a nice
diagnostic
honk.m:6:4: error: unknown receiver 'Hnk'; did you mean 'Honk'?
[Hnk method];
^~~
Honk
honk.m:1:1: note: 'Honk' declared here
@interface Honk
^
which includes a fix-it.
We still need to recover better from mis-typing "super".
llvm-svn: 101211
we don't have enough information to tell them how to use 'strncmp'. Instead, change the
diagnostic to indicate they should use 'strncmp'.
llvm-svn: 100890
Remove -faccess-control from -cc1; add -fno-access-control.
Make the driver pass -fno-access-control by default.
Update a bunch of tests to be correct under access control.
llvm-svn: 100880
Richard Smith