| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
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.
llvm-svn: 122535
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pack expansions, e.g. given
template<typename... Types> struct tuple;
template<typename... Types>
struct tuple_of_refs {
typedef tuple<Types&...> types;
};
the type of the "types" typedef is a PackExpansionType whose pattern
is Types&.
This commit introduces support for creating pack expansions for
template type arguments, as above, but not for any other kind of pack
expansion, nor for any form of instantiation.
llvm-svn: 122223
|
|
|
|
|
|
| |
Recover from the latter and fail early for the former. Fixes PR8022.
llvm-svn: 118669
|
|
|
|
|
|
|
|
| |
themselves have no template parameters. This is actually a restriction
due to the grammar of template template parameters, but we choose to
diagnose it in Sema to provide better recovery.
llvm-svn: 117032
|
|
|
|
|
|
| |
list, complain about it! Fixes PR7053.
llvm-svn: 116551
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
M-x query-replace-regexp
\(Sema::\|Action::\|Parser::\|\)Owning\(Expr\|Stmt\)Result -> \2Result
llvm-svn: 111903
|
|
|
|
| |
llvm-svn: 111901
|
|
|
|
| |
llvm-svn: 111863
|
|
|
|
|
|
| |
through the parser.
llvm-svn: 111800
|
|
|
|
| |
llvm-svn: 111796
|
|
|
|
| |
llvm-svn: 111795
|
|
|
|
| |
llvm-svn: 111733
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
| |
llvm-svn: 110441
|
|
|
|
|
|
|
|
| |
purpose of access control. Fixes PR7644.
I can't actually find anything directly justifying this, but it seems obvious.
llvm-svn: 108521
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameters starts at the end of the template-parameter rather than at
the point where the template parameter name is encounted. For example,
given:
typedef unsigned char T;
template<typename T = T> struct X0 { };
The "T" in the default argument refers to the typedef of "unsigned
char", rather than referring to the newly-introduced template type
parameter 'T'.
Addresses <rdar://problem/8122812>.
llvm-svn: 107354
|
|
|
|
|
|
|
|
|
|
|
| |
(or operator-function-id) as a template, but the context is actually
non-dependent or the current instantiation, allow us to use knowledge
of what kind of template it is, e.g., type template vs. function
template, for further syntactic disambiguation. This allows us to
parse properly in the presence of stray "template" keywords, which is
necessary in C++0x and it's good recovery in C++98/03.
llvm-svn: 106167
|
|
|
|
|
|
|
|
|
| |
disambiguation keywords outside of templates in C++98/03. Previously,
the warning would fire when the associated nested-name-specifier was
not dependent, but that was a misreading of the C++98/03 standard:
now, we complain only when we're outside of any template.
llvm-svn: 106161
|
|
|
|
|
|
| |
type-parameter within a template parameter list. Found by inspection.
llvm-svn: 105462
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the required "template" keyword, using the same heuristics we do for
dependent template names in member access expressions, e.g.,
test/SemaTemplate/dependent-template-recover.cpp:11:8: error: use 'template'
keyword to treat 'getAs' as a dependent template name
T::getAs<U>();
^
template
Fixes PR5404.
llvm-svn: 104409
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that is missing the 'template' keyword, e.g.,
t->getAs<T>()
where getAs is a member of an unknown specialization. C++ requires
that we treat "getAs" as a value, but that would fail to parse since T
is the name of a type. We would then fail at the '>', since a type
cannot be followed by a '>'.
This is a very common error for C++ programmers to make, especially
since GCC occasionally allows it when it shouldn't (as does Visual
C++). So, when we are in this case, we use tentative parsing to see if
the tokens starting at "<" can only be parsed as a template argument
list. If so, we produce a diagnostic with a fix-it that states that
the 'template' keyword is needed:
test/SemaTemplate/dependent-template-recover.cpp:5:8: error: 'template' keyword
is required to treat 'getAs' as a dependent template name
t->getAs<T>();
^
template
This is just a start of this patch; I'd like to apply the same
approach to everywhere that a template-id with dependent template name
can be parsed.
llvm-svn: 104406
|
|
|
|
|
|
| |
Fixes <rdar://problem/7987650>.
llvm-svn: 104376
|
|
|
|
|
|
| |
the C-only "optimization".
llvm-svn: 100022
|
|
|
|
| |
llvm-svn: 100018
|
|
|
|
|
|
|
| |
term "fix-it" everywhere and even *I* get tired of long names
sometimes. No functionality change.
llvm-svn: 100008
|
|
|
|
|
|
| |
sure that the new token's range extends to the end of the old token. Assert that in AnnotateCachedTokens. Fixes PR6248.
llvm-svn: 95555
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 92177
|
|
|
|
| |
llvm-svn: 91024
|
|
|
|
|
|
| |
of dirty data around.
llvm-svn: 91002
|
|
|
|
| |
llvm-svn: 90044
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
"typename" parameter to distinguish between non-type and type template
parameters. Fixes the actual bug in PR5559.
llvm-svn: 89532
|
|
|
|
|
|
| |
definition of a member template (or a member thereof). Fixes PR5566.
llvm-svn: 89512
|
|
|
|
|
|
|
|
|
|
|
| |
annotation token, because some of the tokens we're annotating might
not be in the set of cached tokens (we could have consumed them
unconditionally).
Also, move the tentative parsing from ParseTemplateTemplateArgument
into the one caller that needs it, improving recovery.
llvm-svn: 86904
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameters. Rather than storing them as either declarations (for the
non-dependent case) or expressions (for the dependent case), we now
(always) store them as TemplateNames.
The primary change here is to add a new kind of TemplateArgument,
which stores a TemplateName. However, making that change ripples to
every switch on a TemplateArgument's kind, also affecting
TemplateArgumentLocInfo/TemplateArgumentLoc, default template
arguments for template template parameters, type-checking of template
template arguments, etc.
This change is light on testing. It should fix several pre-existing
problems with template template parameters, such as:
- the inability to use dependent template names as template template
arguments
- template template parameter default arguments cannot be
instantiation
However, there are enough pieces missing that more implementation is
required before we can adequately test template template parameters.
llvm-svn: 86777
|
|
|
|
| |
llvm-svn: 86719
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
single typename annotation token when backtracing. Fixes PR5350.
llvm-svn: 86034
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
overloaded operators, e.g.,
p->template operator+<T>()
llvm-svn: 85989
|
|
|
|
|
|
| |
partial specializations and explicit instantiations of non-templates.
llvm-svn: 85620
|
|
|
|
| |
llvm-svn: 81346
|
|
|
|
|
|
| |
then drop it on the floor.
llvm-svn: 80989
|
|
|
|
|
|
|
|
|
|
| |
member templates declared inside other templates. This allows us to
match out-of-line definitions of member function templates within
class templates to the declarations within the class template. We
still can't handle out-of-line definitions for member class templates,
however.
llvm-svn: 79955
|
|
|
|
| |
llvm-svn: 79570
|
|
|
|
| |
llvm-svn: 79558
|