default arguments of function parameters. This simple-sounding task is
complicated greatly by two issues:
(1) Default arguments aren't actually a real context, so we need to
maintain extra state within lambda expressions to track when a
lambda was actually in a default argument.
(2) At the time that we parse a default argument, the FunctionDecl
doesn't exist yet, so lambda closure types end up in the enclosing
context. It's not clear that we ever want to change that, so instead
we introduce the notion of the "effective" context of a declaration
for the purposes of name mangling.
llvm-svn: 151011
For compatibility with gcc, clang will now parse gcc attributes on
function definitions, but issue a warning if the attribute is not a
thread safety attribute. Warning controlled by -Wgcc-compat.
llvm-svn: 150698
instead of having a special-purpose function.
- ActOnCXXDirectInitializer, which was mostly duplication of
AddInitializerToDecl (leading e.g. to PR10620, which Eli fixed a few days
ago), is dropped completely.
- MultiInitializer, which was an ugly hack I added, is dropped again.
- We now have the infrastructure in place to distinguish between
int x = {1};
int x({1});
int x{1};
-- VarDecl now has getInitStyle(), which indicates which of the above was used.
-- CXXConstructExpr now has a flag to indicate that it represents list-
initialization, although this is not yet used.
- InstantiateInitializer was renamed to SubstInitializer and simplified.
- ActOnParenOrParenListExpr has been replaced by ActOnParenListExpr, which
always produces a ParenListExpr. Placed that so far failed to convert that
back to a ParenExpr containing comma operators have been fixed. I'm pretty
sure I could have made a crashing test case before this.
The end result is a (I hope) considerably cleaner design of initializers.
More importantly, the fact that I can now distinguish between the various
initialization kinds means that I can get the tricky generalized initializer
test cases Johannes Schaub supplied to work. (This is not yet done.)
This commit passed self-host, with the resulting compiler passing the tests. I
hope it doesn't break more complicated code. It's a pretty big change, but one
that I feel is necessary.
llvm-svn: 150318
Parsing of @implementations was based on modifying global state from
the parser; the logic for late parsing of methods was spread in multiple places
making it difficult to have a robust error recovery.
-it was difficult to ensure that we don't neglect parsing the lexed methods.
-it was difficult to setup the original objc container context for parsing the lexed methods
after completing ParseObjCAtImplementationDeclaration and returning to top level context.
Enhance parsing of @implementations by centralizing it in Parser::ParseObjCAtImplementationDeclaration().
ParseObjCAtImplementationDeclaration now returns only after an @implementation is fully parsed;
all the data and logic for late parsing of methods is now in one place.
This allows us to provide code-completion for late parsed methods with mis-matched braces.
rdar://10775381
llvm-svn: 149987
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
the Semantic Powers to only warn on class types (or dependent types), where the
constructor or destructor could do something interesting.
llvm-svn: 147642
scope, when no other indication is provided that the user intended to declare a
function rather than a variable.
Remove some false positives from the existing 'parentheses disambiguated as a
function' warning by suppressing it when the declaration is marked as 'typedef'
or 'extern'.
Add a new warning group -Wvexing-parse containing both of these warnings.
The new warning is enabled by default; despite a number of false positives (and
one bug) in clang's test-suite, I have only found genuine bugs with it when
running it over a significant quantity of real C++ code.
llvm-svn: 147599
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
The main motivation was to do typo correction in C++ "new" statements,
though picking it up in other places where type names are expected was
pretty much a freebie.
llvm-svn: 141621
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
