| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
"->" with a use of ParseUnqualifiedId. Collapse
ActOnMemberReferenceExpr, ActOnDestructorReferenceExpr (both of them),
ActOnOverloadedOperatorReferenceExpr,
ActOnConversionOperatorReferenceExpr, and
ActOnMemberTemplateIdReferenceExpr into a single, new action
ActOnMemberAccessExpr that does the same thing more cleanly (and can
keep more source-location information).
llvm-svn: 85930
|
|
|
|
|
|
|
| |
declarators are parsed primarily within a single function (at least for
these cases). Remove some excess diagnostics arising during parse failures.
llvm-svn: 85924
|
|
|
|
|
|
| |
it easier to track within Sema whether the parser is parsing a declaration.
llvm-svn: 85855
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
representation of a C++ unqualified-id, along with a single parsing
function (Parser::ParseUnqualifiedId) that will parse all of the
various forms of unqualified-id in C++.
Replace the representation of the declarator name in Declarator with
the new UnqualifiedId class, simplifying declarator-id parsing
considerably and providing more source-location information to
Sema. In the future, I hope to migrate all of the other
unqualified-id-parsing code over to this single representation, then
begin to merge actions that are currently only different because we
didn't have a unqualified notion of the name in the parser.
llvm-svn: 85851
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unknown type name, e.g.,
foo::bar x;
when "bar" does not refer to a type in "foo".
With this change, the parser now calls into the action to perform
diagnostics and can try to recover by substituting in an appropriate
type. For example, this allows us to easily diagnose some missing
"typename" specifiers, which we now do:
test/SemaCXX/unknown-type-name.cpp:29:1: error: missing 'typename'
prior to dependent type name 'A<T>::type'
A<T>::type A<T>::f() { return type(); }
^~~~~~~~~~
typename
Fixes PR3990.
llvm-svn: 84053
|
|
|
|
| |
llvm-svn: 83091
|
|
|
|
|
|
| |
type name within the declaration specifiers. Fixes PR5061.
llvm-svn: 82974
|
|
|
|
|
|
|
|
|
|
|
| |
template void f<int>(int);
~~~~~~
Previously, we silently dropped the template arguments. With this
change, we now use the template arguments (when available) as the
explicitly-specified template arguments used to aid template argument
deduction for explicit template instantiations.
llvm-svn: 82806
|
|
|
|
|
|
|
|
| |
member functions of class template specializations, and static data
members. The mechanics are (mostly) present, but the semantic analysis
is very weak.
llvm-svn: 82789
|
|
|
|
|
|
| |
Parse it in both C and C++, but diagnose it as an error in C with a fix-it hint to add the comma.
llvm-svn: 82576
|
|
|
|
|
|
| |
expression, or statement
llvm-svn: 82481
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
will provide the names of various enumerations currently
visible. Introduced filtering of code-completion results when we build
the result set, so that we can identify just the kinds of declarations
we want.
This implementation is incomplete for C++, since we don't consider
that the token after the tag keyword could start a
nested-name-specifier.
llvm-svn: 82222
|
|
|
|
| |
llvm-svn: 81504
|
|
|
|
| |
llvm-svn: 81346
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
x->Base::f
We no longer try to "enter" the context of the type that "x" points
to. Instead, we drag that object type through the parser and pass it
into the Sema routines that need to know how to perform lookup within
member access expressions.
We now implement most of the crazy name lookup rules in C++
[basic.lookup.classref] for non-templated code, including performing
lookup both in the context of the type referred to by the member
access and in the scope of the member access itself and then detecting
ambiguities when the two lookups collide (p1 and p4; p3 and p7 are
still TODO). This change also corrects our handling of name lookup
within template arguments of template-ids inside the
nested-name-specifier (p6; we used to look into the scope of the
object expression for them) and fixes PR4703.
I have disabled some tests that involve member access expressions
where the object expression has dependent type, because we don't yet
have the ability to describe dependent nested-name-specifiers starting
with an identifier.
llvm-svn: 80843
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TypenameType if getTypeName is looking at a member of an unknown
specialization. This allows us to properly parse class templates that
derived from type that could only otherwise be described by a typename type,
e.g.,
template<class T> struct X {};
template<typename T> struct Y : public X<T>::X { };
Fixes PR4381.
llvm-svn: 80123
|
|
|
|
|
|
| |
Bagnara with a fix from Enea Zaffanella!
llvm-svn: 80094
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 80044
|
|
|
|
|
|
|
|
| |
and will participate in overload resolution. Unify the instantiation
of CXXMethodDecls and CXXConstructorDecls, which had already gotten
out-of-sync.
llvm-svn: 79658
|
|
|
|
| |
llvm-svn: 79489
|
|
|
|
|
|
| |
create the CXXExprWithTemporaries before setting the initializer on the VarDecl.
llvm-svn: 79176
|
|
|
|
| |
llvm-svn: 78471
|
|
|
|
| |
llvm-svn: 78274
|
|
|
|
|
|
|
|
| |
elsewhere. Very slightly decouples DeclSpec users from knowing the exact
diagnostics to report, and makes it easier to provide different diagnostics in
some places.
llvm-svn: 77990
|
|
|
|
|
|
| |
and a name collision.
llvm-svn: 77658
|
|
|
|
| |
llvm-svn: 77656
|
|
|
|
|
|
|
|
|
| |
point that covers templates and non-templates. This should eliminate
the flood of warnings I introduced yesterday.
Removed the ActOnClassTemplate action, which is no longer used.
llvm-svn: 76881
|
|
|
|
|
|
| |
a destructor.
llvm-svn: 76436
|
|
|
|
|
|
| |
an incremental patch
llvm-svn: 75622
|
|
|
|
| |
llvm-svn: 75591
|
|
|
|
|
|
| |
have an initializer. Also, move some tests around to match the C++0x draft better.
llvm-svn: 75322
|
|
|
|
| |
llvm-svn: 74833
|
|
|
|
|
|
| |
from Enea Zaffanella!
llvm-svn: 74831
|
|
|
|
|
|
|
|
|
| |
ParseDeclarationSpecifiers ... from ParseObjCTypeName)
Another case where we should use SmallVector::data() instead of taking the
address of element 0 of a SmallVector when the SmallVector has no elements.
llvm-svn: 74556
|
|
|
|
| |
llvm-svn: 74358
|
|
|
|
| |
llvm-svn: 74307
|
|
|
|
| |
llvm-svn: 74280
|
|
|
|
| |
llvm-svn: 74086
|
|
|
|
|
|
|
| |
handle function templates. There's no actual code for function
templates yet, but at least we complain about typedef templates.
llvm-svn: 74021
|
|
|
|
|
|
|
| |
specialization. At present, all implicit instantiations occur at the
end of the translation unit.
llvm-svn: 73915
|
|
|
|
|
|
|
|
|
|
|
|
| |
C++. This logic is required to trigger implicit instantiation of
function templates and member functions of class templates, which will
be implemented separately.
This commit includes support for -Wunused-parameter, printing warnings
for named parameters that are not used within a function/Objective-C
method/block. Fixes <rdar://problem/6505209>.
llvm-svn: 73797
|
|
|
|
|
|
|
|
| |
data member.
Fixes "test/CXX/basic/basic.lookup/basic.lookup.unqual/p13.cpp" test case.
llvm-svn: 73652
|
|
|
|
|
|
| |
argument before the function has been declared.
llvm-svn: 73234
|
|
|
|
| |
llvm-svn: 73101
|
|
|
|
|
|
| |
at the moment because we ignore the result.
llvm-svn: 73056
|
|
|
|
| |
llvm-svn: 72664
|
|
|
|
| |
llvm-svn: 72640
|
|
|
|
| |
llvm-svn: 72580
|
|
|
|
|
|
| |
to the DeclGroup.
llvm-svn: 72559
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specifier resulted in the creation of a new TagDecl node, which
happens either when the tag specifier was a definition or when the tag
specifier was the first declaration of that tag type. This information
has several uses, the first of which is implemented in this commit:
1) In C++, one is not allowed to define tag types within a type
specifier (e.g., static_cast<struct S { int x; } *>(0) is
ill-formed) or within the result or parameter types of a
function. We now diagnose this.
2) We can extend DeclGroups to contain information about any tags
that are declared/defined within the declaration specifiers of a
variable, e.g.,
struct Point { int x, y, z; } p;
This will help improve AST printing and template instantiation,
among other things.
3) For C99, we can keep track of whether a tag type is defined
within the type of a parameter, to properly cope with cases like,
e.g.,
int bar(struct T2 { int x; } y) {
struct T2 z;
}
We can also do similar things wherever there is a type specifier,
e.g., to keep track of where the definition of S occurs in this
legal C99 code:
(struct S { int x, y; } *)0
llvm-svn: 72555
|