uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169237 91177308-0d34-0410-b5e6-96231b3b80d8
r128056 moved PrettyStackTraceParserEntry construction from Parser.h
to ParseAST.cpp, so there's no need to keep this class in a header.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168731 91177308-0d34-0410-b5e6-96231b3b80d8
This change list implemented logic that explicitly detects several combinations of locations where C++11 attribute
specifiers might be incorrectly placed within a class specifier. Previously we emit generic diagnostics like
"expected identifier" for such cases; now we emit specific diagnostic against the misplaced attributes, this also
fixed a bug in old code where attributes appear at legitimate locations were incorrectly rejected.
Thanks to Richard Smith for reviewing!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168626 91177308-0d34-0410-b5e6-96231b3b80d8
dropping the specifier, just like we do for non-member functions and function
templates declared 'typedef'. Patch by Brian Brooks!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168108 91177308-0d34-0410-b5e6-96231b3b80d8
/// \param TemplateParams if non-NULL, the template parameter lists
/// that preceded this declaration. In this case, the declaration is a
/// template declaration, out-of-line definition of a template, or an
/// explicit template specialization. When NULL, the declaration is an
/// explicit template instantiation.
///
/// \param TemplateLoc when TemplateParams is NULL, the location of
/// the 'template' keyword that indicates that we have an explicit
/// template instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167982 91177308-0d34-0410-b5e6-96231b3b80d8
positions of Objective-C methods.
It is possible to recover a lot of type information about
Objective-C methods from the reflective metadata for their
implementations. This information is not rich when it
comes to struct types, however, and it is not possible to
produce a type in the debugger's round-tripped AST which
will really do anything useful during type-checking.
Therefore we allow __unknown_anytype in these positions,
which essentially disables type-checking for that argument.
We infer the parameter type to be the unqualified type of
the argument expression unless that expression is an
explicit cast, in which case it becomes the type-as-written
of that cast.
rdar://problem/12565338
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167896 91177308-0d34-0410-b5e6-96231b3b80d8
Introduces more clear scoping flags & flag combinations which should hopefully
be more understandable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167766 91177308-0d34-0410-b5e6-96231b3b80d8
C++11 3.3.3/2 "A parameter name shall not be redeclared in the outermost block
of the function definition nor in the outermost block of any handler associated
with a function-try-block."
It's not totally clear to me whether the "FIXME" case is covered by this, but
Richard Smith thinks it probably should be. It's just a bit more involved to
fix that case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167650 91177308-0d34-0410-b5e6-96231b3b80d8
We don't support any C++11 attributes that appertain to declaration specifiers so reject
the attributes in parser until we support them; this also conforms to what g++ 4.8 is doing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167481 91177308-0d34-0410-b5e6-96231b3b80d8
token. This is important because the first token could actually be
after an #include that triggers a module import, which might use
either Sema or the AST consumer before it would have been initialized.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167423 91177308-0d34-0410-b5e6-96231b3b80d8
is at the end of parsed tokens when an error occurs, otherwise we'll hit
an assertion when trying to annotate the decltype tokens.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166826 91177308-0d34-0410-b5e6-96231b3b80d8
declarations and statements. Emit an error if the FP_CONTRACT is used
later in a compound statement.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166383 91177308-0d34-0410-b5e6-96231b3b80d8
auto x((unknown));
int& y = x;
would crash because we were not flagging 'x' as an invalid declaration here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165675 91177308-0d34-0410-b5e6-96231b3b80d8
I think our general framework for parser pragmas needs a bit more work,
but I'm not planning on working on it at the moment.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165558 91177308-0d34-0410-b5e6-96231b3b80d8
For GNU attributes, instead of reusing attribute source
location for the scope location, use SourceLocation() since
GNU attributes don not have scope tokens.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165234 91177308-0d34-0410-b5e6-96231b3b80d8
- General C++11 attributes were previously parsed and ignored. Now they are parsed and stored in AST.
- Add support to parse arguments of attributes that in 'gnu' namespace.
- Differentiate unknown attributes and known attributes that can't be applied to statements when emitting diagnostic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165082 91177308-0d34-0410-b5e6-96231b3b80d8
Clang will now honor the FP_CONTRACT pragma and emit LLVM
fmuladd intrinsics for expressions of the form A * B + C (when they occur in a
single statement).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164989 91177308-0d34-0410-b5e6-96231b3b80d8
typeid (and a couple other non-standard places where we can transform an
unevaluated expression into an evaluated expression) is special
because it introduces an an expression evaluation context,
which conflicts with the mechanism to compute the current
lambda mangling context. PR12123.
I would appreciate if someone would double-check that we get the mangling
correct with this patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164658 91177308-0d34-0410-b5e6-96231b3b80d8