| Age | Commit message (Collapse) | Author |
|---|
|
the C-only "optimization".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100022 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100018 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
term "fix-it" everywhere and even *I* get tired of long names
sometimes. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@100008 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
sure that the new token's range extends to the end of the old token. Assert that in AnnotateCachedTokens. Fixes PR6248.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@95555 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@93322 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@92177 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91024 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of dirty data around.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91002 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@90044 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
|
|
"typename" parameter to distinguish between non-type and type template
parameters. Fixes the actual bug in PR5559.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89532 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
definition of a member template (or a member thereof). Fixes PR5566.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@89512 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86904 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86777 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86719 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86708 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
single typename annotation token when backtracing. Fixes PR5350.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@86034 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85998 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
overloaded operators, e.g.,
p->template operator+<T>()
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85989 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
partial specializations and explicit instantiations of non-templates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85620 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81346 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
then drop it on the floor.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80989 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79955 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79570 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79558 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77656 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
templates, e.g.,
template<typename T>
struct Outer {
struct Inner;
};
template<typename T>
struct Outer<T>::Inner {
// ...
};
Implementing this feature required some extensions to ActOnTag, which
now takes a set of template parameter lists, and is the precursor to
removing the ActOnClassTemplate function from the parser Action
interface. The reason for this approach is simple: the parser cannot
tell the difference between a class template definition and the
definition of a member of a class template; both have template
parameter lists, and semantic analysis determines what that template
parameter list means.
There is still some cleanup to do with ActOnTag and
ActOnClassTemplate. This commit provides the basic functionality we
need, however.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76820 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
this case
but at least we don't crash :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74264 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
ActOnFunctionDeclarator for function template definitions
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74040 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
handle function templates. There's no actual code for function
templates yet, but at least we complain about typedef templates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@74021 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
compilation, and (hopefully) introduce RAII objects for changing the
"potentially evaluated" state at all of the necessary places within
Sema and Parser. Other changes:
- Set the unevaluated/potentially-evaluated context appropriately
during template instantiation.
- We now recognize three different states while parsing or
instantiating expressions: unevaluated, potentially evaluated, and
potentially potentially evaluated (for C++'s typeid).
- When we're in a potentially potentially-evaluated context, queue
up MarkDeclarationReferenced calls in a stack. For C++ typeid
expressions that are potentially evaluated, we will play back
these MarkDeclarationReferenced calls when we exit the
corresponding potentially potentially-evaluated context.
- Non-type template arguments are now parsed as constant
expressions, so they are not potentially-evaluated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73899 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73267 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73247 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
redundant functionality. The result (ASTOwningVector) lives in
clang/Parse/Ownership.h and is used by both the parser and semantic
analysis. No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72214 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72210 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template class X<int>;
This also cleans up the propagation of template information through
declaration parsing, which is used to improve some diagnostics.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71608 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
parse just a single declaration and provide a reasonable diagnostic
when the "only one declarator per template declaration" rule is
violated. This eliminates some ugly, ugly hackery where we used to
require thatn the layout of a DeclGroup of a single element be the
same as the layout of a single declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71596 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of the range is now the ';' location. For something like this:
$ cat t2.c
#define bool int
void f(int x, int y) {
bool b = !x && y;
}
We used to produce:
$ clang-cc t2.c -ast-dump
typedef char *__builtin_va_list;
void f(int x, int y)
(CompoundStmt 0x2201f10 <t2.c:3:22, line:5:1>
(DeclStmt 0x2201ef0 <line:2:14> <----
0x2201a20 "int b =
(BinaryOperator 0x2201ed0 <line:4:10, col:16> 'int' '&&'
(UnaryOperator 0x2201e90 <col:10, col:11> 'int' prefix '!'
(DeclRefExpr 0x2201c90 <col:11> 'int' ParmVar='x' 0x2201a50))
(DeclRefExpr 0x2201eb0 <col:16> 'int' ParmVar='y' 0x2201e10))")
Now we produce:
$ clang-cc t2.c -ast-dump
typedef char *__builtin_va_list;
void f(int x, int y)
(CompoundStmt 0x2201f10 <t2.c:3:22, line:5:1>
(DeclStmt 0x2201ef0 <line:2:14, line:4:17> <------
0x2201a20 "int b =
(BinaryOperator 0x2201ed0 <col:10, col:16> 'int' '&&'
(UnaryOperator 0x2201e90 <col:10, col:11> 'int' prefix '!'
(DeclRefExpr 0x2201c90 <col:11> 'int' ParmVar='x' 0x2201a50))
(DeclRefExpr 0x2201eb0 <col:16> 'int' ParmVar='y' 0x2201e10))")
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68288 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
failures that involve malformed types, e.g., "typename X::foo" where
"foo" isn't a type, or "std::vector<void>" that doens't instantiate
properly.
Similarly, be a bit smarter in our handling of ambiguities that occur
in Sema::getTypeName, to eliminate duplicate error messages about
ambiguous name lookup.
This eliminates two XFAILs in test/SemaCXX, one of which was crying
out to us, trying to tell us that we were producing repeated error
messages.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68251 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
within nested-name-specifiers, e.g., for the "apply" in
typename MetaFun::template apply<T1, T2>::type
At present, we can't instantiate these nested-name-specifiers, so our
testing is sketchy.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68081 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
representation handles the various ways in which one can name a
template, including unqualified references ("vector"), qualified
references ("std::vector"), and dependent template names
("MetaFun::template apply").
One immediate effect of this change is that the representation of
nested-name-specifiers in type names for class template
specializations (e.g., std::vector<int>) is more accurate. Rather than
representing std::vector<int> as
std::(vector<int>)
we represent it as
(std::vector)<int>
which more closely follows the C++ grammar.
Additionally, templates are no longer represented as declarations
(DeclPtrTy) in Parse-Sema interactions. Instead, I've introduced a new
OpaquePtr type (TemplateTy) that holds the representation of a
TemplateName. This will simplify the handling of dependent
template-names, once we get there.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68074 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
productions (except the already broken ObjC cases like @class X,Y;) in
the parser that can produce more than one Decl return a DeclGroup instead
of a Decl, etc.
This allows elimination of the Decl::NextDeclarator field, and exposes
various clients that should look at all decls in a group, but which were
only looking at one (such as the dumper, printer, etc). These have been
fixed.
Still TODO:
1) there are some FIXME's in the code about potentially using
DeclGroup for better location info.
2) ParseObjCAtDirectives should return a DeclGroup due to @class etc.
3) I'm not sure what is going on with StmtIterator.cpp, or if it can
be radically simplified now.
4) I put a truly horrible hack in ParseTemplate.cpp.
I plan to bring up #3/4 on the mailing list, but don't plan to tackle
#1/2 in the short term.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68002 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
pointer. Its purpose in life is to be a glorified void*, but which does not
implicitly convert to void* or other OpaquePtr's with a different UID.
Introduce Action::DeclPtrTy which is a typedef for OpaquePtr<0>. Change the
entire parser/sema interface to use DeclPtrTy instead of DeclTy*. This
makes the C++ compiler enforce that these aren't convertible to other opaque
types.
We should also convert ExprTy, StmtTy, TypeTy, AttrTy, BaseTy, etc,
but I don't plan to do that in the short term.
The one outstanding known problem with this patch is that we lose the
bitmangling optimization where ActionResult<DeclPtrTy> doesn't know how to
bitmangle the success bit into the low bit of DeclPtrTy. I will rectify
this with a subsequent patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67952 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
all the way down to ActOnClassTemplate.
Doug, Sebastian: Plz review! :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67723 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65641 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
know how to recover from an error, we can attach a hint to the
diagnostic that states how to modify the code, which can be one of:
- Insert some new code (a text string) at a particular source
location
- Remove the code within a given range
- Replace the code within a given range with some new code (a text
string)
Right now, we use these hints to annotate diagnostic information. For
example, if one uses the '>>' in a template argument in C++98, as in
this code:
template<int I> class B { };
B<1000 >> 2> *b1;
we'll warn that the behavior will change in C++0x. The fix is to
insert parenthese, so we use code insertion annotations to illustrate
where the parentheses go:
test.cpp:10:10: warning: use of right-shift operator ('>>') in template
argument will require parentheses in C++0x
B<1000 >> 2> *b1;
^
( )
Use of these annotations is partially implemented for HTML
diagnostics, but it's not (yet) producing valid HTML, which may be
related to PR2386, so it has been #if 0'd out.
In this future, we could consider hooking this mechanism up to the
rewriter to actually try to fix these problems during compilation (or,
after a compilation whose only errors have fixes). For now, however, I
suggest that we use these code modification hints whenever we can, so
that we get better diagnostics now and will have better coverage when
we find better ways to use this information.
This also fixes PR3410 by placing the complaint about missing tokens
just after the previous token (rather than at the location of the next
token).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65570 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
vector<vector<double>> Matrix;
In C++98/03, this token always means "right shift". However, if we're in
a context where we know that it can't mean "right shift", provide a
friendly reminder to put a space between the two >'s and then treat it
as two >'s as part of recovery.
In C++0x, this token is always broken into two '>' tokens.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65484 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
std::vector<int>::allocator_type
When we parse a template-id that names a type, it will become either a
template-id annotation (which is a parsed representation of a
template-id that has not yet been through semantic analysis) or a
typename annotation (where semantic analysis has resolved the
template-id to an actual type), depending on the context. We only
produce a type in contexts where we know that we only need type
information, e.g., in a type specifier. Otherwise, we create a
template-id annotation that can later be "upgraded" by transforming it
into a typename annotation when the parser needs a type. This occurs,
for example, when we've parsed "std::vector<int>" above and then see
the '::' after it. However, it means that when writing something like
this:
template<> class Outer::Inner<int> { ... };
We have two tokens to represent Outer::Inner<int>: one token for the
nested name specifier Outer::, and one template-id annotation token
for Inner<int>, which will be passed to semantic analysis to define
the class template specialization.
Most of the churn in the template tests in this patch come from an
improvement in our error recovery from ill-formed template-ids.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65467 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
us whether there was an error in trying to parse a type-name (type-id
in C++). This allows propagation of errors further in the compiler,
suppressing more bogus error messages.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64922 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
specialization of class templates, e.g.,
template<typename T> class X;
template<> class X<int> { /* blah */ };
Each specialization is a different *Decl node (naturally), and can
have different members. We keep track of forward declarations and
definitions as for other class/struct/union types.
This is only the basic framework: we still have to deal with checking
the template headers properly, improving recovery when there are
failures, handling nested name specifiers, etc.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64848 91177308-0d34-0410-b5e6-96231b3b80d8
|
