We build a NestedNameSpecifier that records the CXXRecordDecl in which
__super appeared. Name lookup is performed in all base classes of the
recorded CXXRecordDecl. Use of __super is allowed only inside class and
member function scope.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@218484 91177308-0d34-0410-b5e6-96231b3b80d8
This commit kills off custom type specifier and keyword handling of OpenCL C
data types.
Although the OpenCL spec describes them as keywords, we can handle them more
elegantly as predefined types. This should provide better error correction and
code completion as well as simplifying the implementation.
The primary intention is however to simplify the C/C++ parser and save some
packed bits on AST structures that had been extended in r170432 just for
OpenCL.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197578 91177308-0d34-0410-b5e6-96231b3b80d8
Type trait parsing is all over the place at the moment with unary, binary and
n-ary C++11 type traits that were developed independently at different points
in clang's history.
There's no good reason to handle them separately -- there are three parsers,
three AST nodes and lots of duplicated handling code with slightly different
implementations and diags for each kind.
This commit unifies parsing of type traits and sets the stage for further
consolidation.
No change in behaviour other than more consistent error recovery.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197179 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Similar to __FUNCTION__, MSVC exposes the name of the enclosing mangled
function name via __FUNCDNAME__. This implementation is very naive and
unoptimized, it is expected that __FUNCDNAME__ would be used rarely in
practice.
Reviewers: rnk, rsmith, thakis
CC: cfe-commits, silvas
Differential Revision: http://llvm-reviews.chandlerc.com/D2109
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194181 91177308-0d34-0410-b5e6-96231b3b80d8
When a comma occurs in a default argument or default initializer within a
class, disambiguate whether it is part of the initializer or whether it ends
the initializer.
The way this works (which I will be proposing for standardization) is to treat
the comma as ending the default argument or default initializer if the
following token sequence matches the syntactic constraints of a
parameter-declaration-clause or init-declarator-list (respectively).
This is both consistent with the disambiguation rules elsewhere (where entities
are treated as declarations if they can be), and should have no regressions
over our old behavior. I think it might also disambiguate all cases correctly,
but I don't have a proof of that.
There is an annoyance here: because we're performing a tentative parse in a
situation where we may not have seen declarations of all relevant entities (if
the comma is part of the initializer, lookup may find entites declared later in
the class), we need to turn off typo-correction and diagnostics during the
tentative parse, and in the rare case that we decide the comma is part of the
initializer, we need to revert all token annotations we performed while
disambiguating.
Any diagnostics that occur outside of the immediate context of the tentative
parse (for instance, if we trigger the implicit instantiation of a class
template) are *not* suppressed, mirroring the usual rules for a SFINAE context.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@190639 91177308-0d34-0410-b5e6-96231b3b80d8
smarts so that it doesn't approve of keywords and/or type names when it
knows (based on its flags) that those kinds of corrections are not
wanted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178668 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
statement starts with an identifier for which name lookup will fail either way,
look at later tokens to disambiguate in order to improve error recovery.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162464 91177308-0d34-0410-b5e6-96231b3b80d8
nested names as id-expressions, using the annot_primary_expr annotation, where
possible. This removes some redundant lookups, and also allows us to
typo-correct within tentative parsing, and to carry on disambiguating past an
identifier which we can determine will fail lookup as both a type and as a
non-type, allowing us to disambiguate more declarations (and thus offer
improved error recovery for such cases).
This also introduces to the parser the notion of a tentatively-declared name,
which is an identifier which we *might* have seen a declaration for in a
tentative parse (but only if we end up disambiguating the tokens as a
declaration). This is necessary to correctly disambiguate cases where a
variable is used within its own initializer.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162159 91177308-0d34-0410-b5e6-96231b3b80d8
accurate by asking the parser whether there was an ambiguity rather than trying
to reverse-engineer it from the DeclSpec. Make the with-parameters case have
better diagnostics by using semantic information to drive the warning,
improving the diagnostics and adding a fixit.
Patch by Nikola Smiljanic. Some minor changes by me to suppress diagnostics for
declarations of the form 'T (*x)(...)', which seem to have a very high false
positive rate, and to reduce indentation in 'warnAboutAmbiguousFunction'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160998 91177308-0d34-0410-b5e6-96231b3b80d8
This behaves like the existing GNU __alignof and C++11 alignof keywords;
most of the patch is simply adding the third token spelling to various places.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159494 91177308-0d34-0410-b5e6-96231b3b80d8
Heavily based on a patch from
Aaron Wishnick <aaron.s.wishnick@gmail.com>.
I'll clean up the duplicated function in CodeGen as
a follow-up, later today or tomorrow.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@159060 91177308-0d34-0410-b5e6-96231b3b80d8
Disambiguate past such a potential problem, and use the absence of 'typename'
to break ties in favor of a parenthesized thingy being an initializer, if
nothing else in the declaration disambiguates it as declaring a function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@156963 91177308-0d34-0410-b5e6-96231b3b80d8
followed by an identifier as declaration specificer (except for ObjC).
This allows e.g. an out-of-line C++ member function definitions to be
recognized as functions and not as variable declarations if the type
name for the first parameter is not recognized as a type--say, when there
is a function name shadowing an enum type name and the parameter is
missing the "enum" keyword needed to distinguish the two.
Note that returning TPResult::Error() instead of TPResult::True()
appears to have the same end result, while TPResult::Ambiguous()
results in a crash.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@155163 91177308-0d34-0410-b5e6-96231b3b80d8
* Alternative tokens (such as 'compl') are treated as identifiers in
attribute names.
* An attribute-list can start with a comma.
* An ellipsis may not be used with either of our currently-supported
C++11 attributes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154381 91177308-0d34-0410-b5e6-96231b3b80d8
* In C++11, '[[' is ill-formed unless it starts an attribute-specifier. Reject
array sizes and array indexes which begin with a lambda-expression. Recover by
parsing the lambda as a lambda.
* In Objective-C++11, either '[' could be the start of a message-send.
Fully disambiguate this case: it turns out that the grammars of message-sends,
lambdas and attributes do not actually overlap. Accept any occurrence of '[['
where either '[' starts a message send, but reject a lambda in an array index
just like in C++11 mode.
Implement a couple of changes to the attribute wording which occurred after our
attributes implementation landed:
* In a function-declaration, the attributes go after the exception specification,
not after the right paren.
* A reference type can have attributes applied.
* An 'identifier' in an attribute can also be a keyword. Support for alternative
tokens (iso646 keywords) in attributes to follow.
And some bug fixes:
* Parse attributes after declarator-ids, even if they are not simple identifiers.
* Do not accept attributes after a parenthesized declarator.
* Accept attributes after an array size in a new-type-id.
* Partially disamiguate 'delete' followed by a lambda. More work is required
here for the case where the lambda-introducer is '[]'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154369 91177308-0d34-0410-b5e6-96231b3b80d8
Specifically, using a an integer outside [0, 1] as a boolean constant seems to
be an easy mistake to make with things like "x == a || b" where the author
intended "x == a || x == b".
The bug caused by calling SkipUntil with three token kinds was also identified
by a VC diagnostic & reported by Francois Pichet as review feedback for my
commit r154163. I've included test cases to verify the error recovery that was
broken/poorly implemented due to this bug.
The other fix (lib/Sema/SemaExpr.cpp) seems like that code was never actually
reached in any of Clang's tests & is related to Objective C features I'm not
familiar with, so I've not been able to construct a test case for it. Perhaps
someone else can.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@154325 91177308-0d34-0410-b5e6-96231b3b80d8
a type specifier and can be combined with unsigned. This allows libstdc++4.7 to
be used with clang in c++98 mode.
Several other changes are still required for libstdc++4.7 to work with clang in
c++11 mode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153999 91177308-0d34-0410-b5e6-96231b3b80d8
necessarily mean we've found a function declarator. If the next token is not
a ')', this is actually a parenthesized pack expansion.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153544 91177308-0d34-0410-b5e6-96231b3b80d8
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152536 91177308-0d34-0410-b5e6-96231b3b80d8
that provides the behavior of the C++11 library trait
std::is_trivially_constructible<T, Args...>, which can't be
implemented purely as a library.
Since __is_trivially_constructible can have zero or more arguments, I
needed to add Yet Another Type Trait Expression Class, this one
handling arbitrary arguments. The next step will be to migrate
UnaryTypeTrait and BinaryTypeTrait over to this new, more general
TypeTrait class.
Fixes the Clang side of <rdar://problem/10895483> / PR12038.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151352 91177308-0d34-0410-b5e6-96231b3b80d8
C++11, and with braced-init-list initializers in conditions. This exposed an
ambiguity with enum underlying types versus bitfields, which we resolve by
treating 'enum E : T {' as always defining an enumeration (even if it would
only successfully parse as a bitfield). This appears to be g++ compatible.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151227 91177308-0d34-0410-b5e6-96231b3b80d8
is a declaration-stmt or an expression, we can discern a subset of cases where
the user erred in omitting the typename keyword before a dependent type name.
Fixes PR11358!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148896 91177308-0d34-0410-b5e6-96231b3b80d8
Also drop -Wc1x-extensions in favor of -Wc11-extensions. I don't think we need to keep this around for compatibility.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147221 91177308-0d34-0410-b5e6-96231b3b80d8
lifetime is well-known and restricted, cleaning them up manually is easy to miss and cause a leak.
Use it to plug the leaking of TemplateIdAnnotation objects. rdar://9634138.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@133610 91177308-0d34-0410-b5e6-96231b3b80d8
Otherwise statements like:
__int64 var = __int64(0);
would be expanded to:
long long var = long long(0);
and fail to compile.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130369 91177308-0d34-0410-b5e6-96231b3b80d8
'__is_literal' type trait for GCC compatibility. At least one relased
version if libstdc++ uses this name for the trait despite it not being
documented anywhere.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130078 91177308-0d34-0410-b5e6-96231b3b80d8
This introduces a few APIs on the AST to bundle up the standard-based
logic so that programmatic clients have access to exactly the same
behavior.
There is only one serious FIXME here: checking for non-trivial move
constructors and move assignment operators. Those bits need to be added
to the declaration and accessors provided.
This implementation should be enough for the uses of __is_trivial in
libstdc++ 4.6's C++98 library implementation.
Ideas for more thorough test cases or any edge cases missing would be
appreciated. =D
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@130057 91177308-0d34-0410-b5e6-96231b3b80d8
AttributeLists do not accumulate over the lifetime of parsing, but are
instead reused. Also make the arguments array not require a separate
allocation, and make availability attributes store their stuff in
augmented memory, too.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@128209 91177308-0d34-0410-b5e6-96231b3b80d8
Change the interface to expose the new information and deal with the enormous fallout.
Introduce the new ExceptionSpecificationType value EST_DynamicNone to more easily deal with empty throw specifications.
Update the tests for noexcept and fix the various bugs uncovered, such as lack of tentative parsing support.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@127537 91177308-0d34-0410-b5e6-96231b3b80d8
template specialization types. This also required some parser tweaks,
since we were losing track of the nested-name-specifier's source
location information in several places in the parser. Other notable
changes this required:
- Sema::ActOnTagTemplateIdType now type-checks and forms the
appropriate type nodes (+ source-location information) for an
elaborated-type-specifier ending in a template-id. Previously, we
used a combination of ActOnTemplateIdType and
ActOnTagTemplateIdType that resulted in an ElaboratedType wrapped
around a DependentTemplateSpecializationType, which duplicated the
keyword ("class", "struct", etc.) and nested-name-specifier
storage.
- Sema::ActOnTemplateIdType now gets a nested-name-specifier, which
it places into the returned type-source location information.
- Sema::ActOnDependentTag now creates types with source-location
information.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@126808 91177308-0d34-0410-b5e6-96231b3b80d8
semantics after the C++0x is_convertible type trait. This
implementation is not 100% complete, because it allows access errors
to be hard errors (rather than just evaluating false).
Original patch by Steven Watanabe!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@124425 91177308-0d34-0410-b5e6-96231b3b80d8
involving rvalue references, to start scoping out what is and what
isn't implemented. In the process, tweak some standards citations,
type desugaring, and teach the tentative parser about && in
ptr-operator.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@123913 91177308-0d34-0410-b5e6-96231b3b80d8
on array and function declarators. This is pretty far from complete, and I'll
revisit it later if someone doesn't beat me to it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122535 91177308-0d34-0410-b5e6-96231b3b80d8
parameter packs (C++0x [dcl.fct]p13), including disambiguation between
unnamed function parameter packs and varargs (C++0x [dcl.fct]p14) for
cases like
void f(T...)
where T may or may not contain unexpanded parameter packs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@122520 91177308-0d34-0410-b5e6-96231b3b80d8
disambiguate between an expression (for a bit-field width) and a type
(for a fixed underlying type). Since the disambiguation can be
expensive (due to tentative parsing), we perform a simplistic
disambiguation based on one-token lookahead before going into the
full-blown tentative parsing. Based on a patch by Daniel Wallin.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@120582 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@114057 91177308-0d34-0410-b5e6-96231b3b80d8
"__attribute((pascal))" or "__pascal" (and "_pascal" under
-fborland-extensions). Support still needs to be added to llvm.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@112939 91177308-0d34-0410-b5e6-96231b3b80d8
- move DeclSpec &c into the Sema library
- move ParseAST into the Parse library
Reflect this change in a thousand different includes.
Reflect this change in the link orders.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@111667 91177308-0d34-0410-b5e6-96231b3b80d8
parser is looking at a declaration or an expression, use a '=' to
conclude that we are parsing a declaration.
This is wrong. However, our previous approach of finding a comma after
the '=' is also wrong, because the ',' could be part of a
template-argument-list. So, for now we're going to use the same wrong
heuristic as GCC and Visual C++, because less real-world code is
likely to be broken this way. I've opened PR7655 to keep track of our
wrongness; note also the XFAIL'd test.
Fixes <rdar://problem/8193163>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@108459 91177308-0d34-0410-b5e6-96231b3b80d8
propagating error conditions out of the various annotate-me-a-snowflake
routines. Generally (but not universally) removes redundant diagnostics
as well as, you know, not crashing on bad code. On the other hand,
I have just signed myself up to fix fiddly parser errors for the next
week. Again.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@97221 91177308-0d34-0410-b5e6-96231b3b80d8
scope specifiers. Fix a tentative parsing bug that came up in LLVM.
Incidentally fixes some random FIXMEs in an existing testcase.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91734 91177308-0d34-0410-b5e6-96231b3b80d8
The following attributes are currently supported in C++0x attribute
lists (and in GNU ones as well):
- align() - semantics believed to be conformant to n3000, except for
redeclarations and what entities it may apply to
- final - semantics believed to be conformant to CWG issue 817's proposed
wording, except for redeclarations
- noreturn - semantics believed to be conformant to n3000, except for
redeclarations
- carries_dependency - currently ignored (this is an optimization hint)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89543 91177308-0d34-0410-b5e6-96231b3b80d8
their members, including member class template, member function
templates, and member classes and functions of member templates.
To actually parse the nested-name-specifiers that qualify the name of
an out-of-line definition of a member template, e.g.,
template<typename X> template<typename Y>
X Outer<X>::Inner1<Y>::foo(Y) {
return X();
}
we need to look for the template names (e.g., "Inner1") as a member of
the current instantiation (Outer<X>), even before we have entered the
scope of the current instantiation. Since we can't do this in general
(i.e., we should not be looking into all dependent
nested-name-specifiers as if they were the current instantiation), we
rely on the parser to tell us when it is parsing a declaration
specifier sequence, and, therefore, when we should consider the
current scope specifier to be a current instantiation.
Printing of complicated, dependent nested-name-specifiers may be
somewhat broken by this commit; I'll add tests for this issue and fix
the problem (if it still exists) in a subsequent commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80044 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation for C++ typename-specifiers such as
typename T::type
The parsing of typename-specifiers is relatively easy thanks to
annotation tokens. When we see the "typename", we parse the
typename-specifier and produce a typename annotation token. There are
only a few places where we need to handle this. We currently parse the
typename-specifier form that terminates in an identifier, but not the
simple-template-id form, e.g.,
typename T::template apply<U, V>
Parsing of nested-name-specifiers has a similar problem, since at this
point we don't have any representation of a class template
specialization whose template-name is unknown.
Semantic analysis is only partially complete, with some support for
template instantiation that works for simple examples.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67875 91177308-0d34-0410-b5e6-96231b3b80d8
Nikola Smiljanic