to modernity. Instead of passing down individual
context objects from parser to sema, establish decl
context in parser and have sema access current context
as needed. I still need to take of Doug's comment for
minor cleanups.
llvm-svn: 138040
This patch special cases the parser for thread safety attributes so that all
attribute arguments are put in the argument list (instead of a special
parameter) since arguments may not otherwise resolve correctly without two-token
lookahead.
This patch also adds checks to make sure that attribute arguments are
lockable objects.
llvm-svn: 137130
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.
llvm-svn: 133610
Language-design credit goes to a lot of people, but I particularly want
to single out Blaine Garst and Patrick Beard for their contributions.
Compiler implementation credit goes to Argyrios, Doug, Fariborz, and myself,
in no particular order.
llvm-svn: 133103
They are actually grammatically considered definitions and parsed
accordingly.
This fixes the outstanding bugs regarding defaulting functions after
their declarations.
We now really nicely diagnose the following construct (try it!)
int foo() = delete, bar;
Still todo: Defaulted functions other than default constructors
Test cases (including for the above construct)
llvm-svn: 131228
Explictly defaultedness is correctly reflected on the AST, but there are
no changes to how that affects the definition of functions or much else
really.
llvm-svn: 130974
as a keyword for the __is_signed type trait. Cope with this conflict
via some hackish recovery: if we see a declaration of the form
static const bool __is_signed
then we stop treating __is_signed as a keyword and instead treat it as
an identifier. It's ugly, but it's better than making the __is_signed
type trait conditional on some language flag. Fixes PR9804.
llvm-svn: 130399
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
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.
llvm-svn: 128209
which versions of an OS provide a certain facility. For example,
void foo()
__attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));
says that the function "foo" was introduced in 10.2, deprecated in
10.4, and completely obsoleted in 10.6. This attribute ties in with
the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that
we want to deploy back to Mac OS X 10.1). There are several concrete
behaviors that this attribute enables, as illustrated with the
function foo() above:
- If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
will result in a deprecation warning, as if we had placed
attribute((deprecated)) on it (but with a better diagnostic)
- If we choose a deployment target >= Mac OS X 10.6, uses of "foo"
will result in an "unavailable" warning (in C)/error (in C++), as
if we had placed attribute((unavailable)) on it
- If we choose a deployment target prior to 10.2, foo() is
weak-imported (if it is a kind of entity that can be weak
imported), as if we had placed the weak_import attribute on it.
Naturally, there can be multiple availability attributes on a
declaration, for different platforms; only the current platform
matters when checking availability attributes.
The only platforms this attribute currently works for are "ios" and
"macosx", since we already have -mxxxx-version-min flags for them and we
have experience there with macro tricks translating down to the
deprecated/unavailable/weak_import attributes. The end goal is to open
this up to other platforms, and even extension to other "platforms"
that are really libraries (say, through a #pragma clang
define_system), but that hasn't yet been designed and we may want to
shake out more issues with this narrower problem first.
Addresses <rdar://problem/6690412>.
As a drive-by bug-fix, if an entity is both deprecated and
unavailable, we only emit the "unavailable" diagnostic.
llvm-svn: 128127
add support for the OpenCL __private, __local, __constant and
__global address spaces, as well as the __read_only, _read_write and
__write_only image access specifiers. Patch originally by ARM;
language-specific address space support by myself.
llvm-svn: 127915
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.
llvm-svn: 126808
nested-name-speciciers within elaborated type names, e.g.,
enum clang::NestedNameSpecifier::SpecifierKind
Fixes in this iteration include:
(1) Compute the type-source range properly for a dependent template
specialization type that starts with "template template-id ::", as
in a member access expression
dep->template f<T>::f()
This is a latent bug I triggered with this change (because now we're
checking the computed source ranges for dependent template
specialization types). But the real problem was...
(2) Make sure to set the qualifier range on a dependent template
specialization type appropriately. This will go away once we push
nested-name-specifier locations into dependent template
specialization types, but it was the source of the
valgrind errors on the buildbots.
llvm-svn: 126765
information for qualifier type names throughout the parser to address
several problems.
The commit message from r126737:
Push nested-name-specifier source location information into elaborated
name types, e.g., "enum clang::NestedNameSpecifier::SpecifierKind".
Aside from the normal changes, this also required some tweaks to the
parser. Essentially, when we're looking at a type name (via
getTypeName()) specifically for the purpose of creating an annotation
token, we pass down the flag that asks for full type-source location
information to be stored within the returned type. That way, we retain
source-location information involving nested-name-specifiers rather
than trying to reconstruct that information later, long after it's
been lost in the parser.
With this change, test/Index/recursive-cxx-member-calls.cpp is showing
much improved results again, since that code has lots of
nested-name-specifiers.
llvm-svn: 126748
nested-name-specifiers throughout the parser, and provide a new class
(NestedNameSpecifierLoc) that contains a nested-name-specifier along
with its type-source information.
Right now, this information is completely useless, because we don't
actually store the source-location information anywhere in the
AST. Call this Step 1/N.
llvm-svn: 126391
several ways. We now warn for more of the return types, and correctly
locate the ignored ones. Also adds fix-it hints to remove the ignored
qualifiers. Fixes much of PR9058, although not all of it.
Patch by Hans Wennborg, a couple of minor style tweaks from me.
llvm-svn: 126321
enum X : long { Value = 0x100000000 };
when in Microsoft-extension mode (-fms-extensions). This (now C++0x)
feature has been supported since Microsoft Visual Studio .NET 2003.
llvm-svn: 126243
* Flag indicating 'we're parsing this auto typed variable's initializer' moved from VarDecl to Sema
* Temporary template parameter list for auto deduction is now allocated on the stack.
* Deduced 'auto' types are now uniqued.
llvm-svn: 126139
separately handle the case of a local declaration-specifier list,
including all types in the set of options. Fixes
<rdar://problem/8790735> and <rdar://problem/8662831>.
llvm-svn: 125594
allow ref-qualifiers on function types used as template type
arguments. GNU actually allows cv-qualifiers on function types in many
places where it shouldn't, so we currently categorize this as a GNU
extension.
llvm-svn: 124584
and turn on __has_feature(cxx_rvalue_references). The core rvalue
references proposal seems to be fully implemented now, pending lots
more testing.
llvm-svn: 124169
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.
llvm-svn: 122520
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.
llvm-svn: 120582
protocol-qualifier list without a leading type (e.g., <#blah#>), don't
complain about it being an archaic protocol-qualifier list unless it
actually parses as one.
llvm-svn: 119805
using new/delete and OwningPtrs. After memory profiling Clang, I witnessed periodic leaks of these
objects; digging deeper into the code, it was clear that our management of these objects was a mess. The ownership rules were murky at best, and not always followed. Worse, there are plenty of error paths where we could screw up.
This patch introduces AttributeList::Factory, which is a factory class that creates AttributeList
objects and then blows them away all at once. While conceptually simple, most of the changes in
this patch just have to do with migrating over to the new interface. Most of the changes have resulted in some nice simplifications.
This new strategy currently holds on to all AttributeList objects during the lifetime of the Parser
object. This is easily tunable. If we desire to have more bound the lifetime of AttributeList
objects more precisely, we can have the AttributeList::Factory object (in Parser) push/pop its
underlying allocator as we enter/leave key methods in the Parser. This means that we get
simple memory management while still having the ability to finely control memory use if necessary.
Note that because AttributeList objects are now BumpPtrAllocated, we may reduce malloc() traffic
in many large files with attributes.
This fixes the leak reported in: <rdar://problem/8650003>
llvm-svn: 118675
missing the opening bracket '[', e.g.,
NSArray <CC>
at function scope. Previously, we would only give trivial completions
(const, volatile, etc.), because we're in a "declaration name"
scope. Now, we also provide completions for class methods of NSArray,
e.g.,
alloc
Note that we already had support for this after the first argument,
e.g.,
NSArray method:x <CC>
would get code completion for class methods of NSArray whose selector
starts with "method:". This was already present because we recover
as if NSArray method:x were a class message send missing the opening
bracket (which was committed in r114057).
llvm-svn: 114078
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
used in the default function argument as "used". Instead, when we
actually use the default argument, make another pass over the
expression to mark any used declarations as "used" at that point. This
addresses two kinds of related problems:
1) We were marking some declarations "used" that shouldn't be,
because we were marking them too eagerly.
2) We were failing to mark some declarations as "used" when we
should, if the first time it was instantiated happened to be an
unevaluated context, we wouldn't mark them again at a later point.
I've also added a potentially-handy visitor class template
EvaluatedExprVisitor, which only visits the potentially-evaluated
subexpressions of an expression. I bet this would have been useful for
noexcept...
Fixes PR5810 and PR8127.
llvm-svn: 113700
with comma-separated lists. We never actually used the comma
locations, nor did we store them in the AST, but we did manage to
waste time during template instantiation to produce fake locations.
llvm-svn: 113495
One who seeks the Tao unlearns something new every day.
Less and less remains until you arrive at non-action.
When you arrive at non-action,
nothing will be left undone.
llvm-svn: 112244
declarator. Here, we can only see a few things (e.g., cvr-qualifiers,
nested name specifiers) and we do not want to provide other non-macro
completions. Previously, we would end up in recovery mode and would
provide a large number of non-relevant completions.
llvm-svn: 111818
- 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.
llvm-svn: 111667
lexed method declarations.
This avoid interference with tokens coming after the point where the default arg tokens were 'injected', e.g. for
typedef struct Inst {
void m(int x=0);
} *InstPtr;
when parsing '0' the next token would be '*' and things would be messed up.
llvm-svn: 110436
a function prototype is followed by a declarator if we
aren't parsing a K&R style identifier list.
Also, avoid skipping randomly after a declaration if a
semicolon is missing. Before we'd get:
t.c:3:1: error: expected function body after function declarator
void bar();
^
Now we get:
t.c:1:11: error: invalid token after top level declarator
void foo()
^
;
llvm-svn: 108105
allows Sema some limited access to the current scope, which we only
use in one way: when Sema is performing some kind of declaration that
is not directly driven by the parser (e.g., due to template
instantiatio or lazy declaration of a member), we can find the Scope
associated with a DeclContext, if that DeclContext is still in the
process of being parsed.
Use this to make the implicit declaration of special member functions
in a C++ class more "scope-less", rather than using the NULL Scope hack.
llvm-svn: 107491
In a line like:
(;
the semicolon leaves Parser:ParenCount unbalanced (it's 1 even though we stopped looking for a right paren).
This may affect later parsing and result in bad recovery for parsing errors.
llvm-svn: 106213
type that we expect to see at a given point in the grammar, e.g., when
initializing a variable, returning a result, or calling a function. We
don't prune the candidate set at all, just adjust priorities to favor
things that should type-check, using an ultra-simplified type system.
llvm-svn: 105128
1) Suppress diagnostics as soon as we form the code-completion
token, so we don't get any error/warning spew from the early
end-of-file.
2) If we consume a code-completion token when we weren't expecting
one, go into a code-completion recovery path that produces the best
results it can based on the context that the parser is in.
llvm-svn: 104585
declarator is incorrect. Not being a typename causes the parser to
dive down into the K&R identifier list handling stuff, which is almost
never the right thing to do.
Before:
r.c:3:17: error: expected ')'
void bar(intptr y);
^
r.c:3:9: note: to match this '('
void bar(intptr y);
^
r.c:3:10: error: a parameter list without types is only allowed in a function definition
void bar(intptr y);
^
After:
r.c:3:10: error: unknown type name 'intptr'; did you mean 'intptr_t'?
void bar(intptr y);
^~~~~~
intptr_t
r.c:1:13: note: 'intptr_t' declared here
typedef int intptr_t;
^
This fixes rdar://7980651 - poor recovery for bad type in the first arg of a C function
llvm-svn: 103783
when they are not complete (since we could not match them up to
anything) and ensuring that enum parsing can cope with dependent
elaborated-type-specifiers. Fixes PR6915 and PR6649.
llvm-svn: 102247
ConsumeAndStoreUntil would stop at tok::unknown when caching an inline method
definition while SkipUntil would go past it while parsing the method.
Fixes PR 6903.
llvm-svn: 102214
intended for redeclarations, fixing those that need it. Fixes PR6831.
This uncovered an issue where the C++ type-specifier-seq parsing logic
would try to perform name lookup on an identifier after it already had
a type-specifier, which could also lead to spurious ambiguity errors
(as in PR6831, but with a different test case).
llvm-svn: 101419
template definition. Do this both by being more tolerant of errors in
our asserts and by not dropping a variable declaration completely when
its initializer is ill-formed. Fixes the crash-on-invalid in PR6375,
but not the original issue.
llvm-svn: 97463
signal an error. This can happen even when the current token is '::' if
this is a ::new or ::delete expression.
This was an oversight in my recent parser refactor; fixes PR 5825.
llvm-svn: 97462
an *almost* always incorrect case. This only does the lookahead
in the insanely unlikely case, so it shouldn't impact performance.
On this testcase:
struct foo {
}
typedef int x;
Before:
t.c:3:9: error: cannot combine with previous 'struct' declaration specifier
typedef int x;
^
After:
t.c:2:2: error: expected ';' after struct
}
^
;
llvm-svn: 97403
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.
llvm-svn: 97221
or that's been hidden by a non-type (in C++).
The ideal C++ diagnostic here would note the hiding declaration, but this
is a good start.
llvm-svn: 96141
we would just leak them all over the place, with no clear ownership of
these objects at all. AttributeList objects would get leaked on both
error and non-error paths.
Note: I introduced the usage of llvm::OwningPtr<AttributeList> to
manage these objects, which is particularly useful for methods with
multiple return sites. In at least one method I used them even when
they weren't strictly necessary because it clarified the ownership
semantics and made the code easier to read. Should the excessive
'take()' and 'reset()' calls become a performance issue we can always
re-evaluate.
Note+1: I believe I have not introduced any double-frees, but it would
be nice for someone to review this.
This fixes <rdar://problem/7635046>.
llvm-svn: 95847
t.c:4:3: error: expected ';' at end of declaration list
int y;
^
t.c:4:8: warning: extra ';' inside a struct or union
int y;
^
t.c:6:1: warning: expected ';' at end of declaration list
};
^
After:
t.c:3:8: error: expected ';' at end of declaration list
int x // expected-error {{expected ';' at end of declaration list}}
^
;
t.c:5:8: warning: expected ';' at end of declaration list
int z
^
;
llvm-svn: 95038
the tag kind (union, struct, class, enum) over to the name of the tag,
if there is a name, since most clients want to point at the name.
llvm-svn: 94424
provide completions for @ keywords. Previously, we only provided
@-completions after an @ was actually typed, which is useful but
probably not the common case.
Also, make sure a few Objective-C 2.0 completions only show up when
Objective-C 2.0 support is enabled (the default).
llvm-svn: 93354
that name constructors, the endless joys of out-of-line constructor
definitions, and various other corner cases that the previous hack
never imagined. Fixes PR5688 and tightens up semantic analysis for
constructor names.
Additionally, fixed a problem where we wouldn't properly enter the
declarator scope of a parenthesized declarator. We were entering the
scope, then leaving it when we saw the ")"; now, we re-enter the
declarator scope before parsing the parameter list.
Note that we are forced to perform some tentative parsing within a
class (call it C) to tell the difference between
C(int); // constructor
and
C (f)(int); // member function
which is rather unfortunate. And, although it isn't necessary for
correctness, we use the same tentative-parsing mechanism for
out-of-line constructors to improve diagnostics in icky cases like:
C::C C::f(int); // error: C::C refers to the constructor name, but
// we complain nicely and recover by treating it as
// a type.
llvm-svn: 93322
C++ grammatical constructs that show up in top-level (namespace-level)
declarations, member declarations, template declarations, statements,
expressions, conditions, etc. For example, we now provide a pattern
for
static_cast<type>(expr)
when we can have an expression, or
using namespace identifier;
when we can have a using directive.
Also, improves the results of code completion at the beginning of a
top-level declaration. Previously, we would see value names (function
names, global variables, etc.); now we see types, namespace names,
etc., but no values.
llvm-svn: 93134
Magically fixes all the terrible lookup problems associated with not pushing
a new scope. Resolves an ancient xfail and an LLVM misparse.
llvm-svn: 91769
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)
llvm-svn: 89543
handling template template parameters properly. This refactoring:
- Parses template template arguments as id-expressions, representing
the result of the parse as a template name (Action::TemplateTy)
rather than as an expression (lame!).
- Represents all parsed template arguments via a new parser-specific
type, ParsedTemplateArgument, which stores the kind of template
argument (type, non-type, template) along with all of the source
information about the template argument. This replaces an ad hoc
set of 3 vectors (one for a void*, which was either a type or an
expression; one for a bit telling whether the first was a type or
an expression; and one for a single source location pointing at
the template argument).
- Moves TemplateIdAnnotation into the new Parse/Template.h. It never
belonged in the Basic library anyway.
llvm-svn: 86708
appears in a deprecated context. In the new strategy, we emit the warnings
as usual unless we're currently parsing a declaration, where "declaration" is
restricted to mean a decl group or a few special cases in Objective C. If
we *are* parsing a declaration, we queue up the deprecation warnings until
the declaration has been completely parsed, and then emit them only if the
decl is not deprecated.
We also standardize the bookkeeping for deprecation so as to avoid special cases.
llvm-svn: 85998
"->" 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
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
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
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
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
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
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
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
Fariborz Jahanian