| Age | Commit message (Collapse) | Author |
|---|
|
such as replacing 'T' in vector<T>. There are a few aspects to this:
- Extend TemplateArgument to allow arbitrary expressions (an
Expr*), and switch ClassTemplateSpecializationType to store
TemplateArguments rather than it's own type-or-expression
representation.
- ClassTemplateSpecializationType can now store dependent types. In
that case, the canonical type is another
ClassTemplateSpecializationType (with default template arguments
expanded) rather than a declaration (we don't build Decls for
dependent types).
- Split ActOnClassTemplateId into ActOnClassTemplateId (called from
the parser) and CheckClassTemplateId (called from
ActOnClassTemplateId and InstantiateType). They're smart enough to
handle dependent types, now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66509 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@66422 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
response to attempts to diagnose an "incomplete" type. This will force
us to use DiagnoseIncompleteType more regularly (rather than looking at
isIncompleteType), but that's also a good thing.
Implicit instantiation is still very simplistic, and will create a new
definition for the class template specialization (as it should) but it
only actually instantiates the base classes and attaches
those. Actually instantiating class members will follow.
Also, instantiate the types of non-type template parameters before
checking them, allowing, e.g.,
template<typename T, T Value> struct Constant;
to work properly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65924 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
array types. Semantic checking for the construction of these types has
been factored out of GetTypeForDeclarator and into separate
subroutines (BuildPointerType, BuildReferenceType,
BuildArrayType). We'll be doing the same thing for all other types
(and declarations and expressions).
As part of this, moved the type-instantiation functions into a class
in an anonymous namespace.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65663 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
stubs for those types we don't yet know how to instantiate (everything
that isn't a template parameter!).
We now instantiate default arguments for template type parameters when
needed. This will be our testbed while I fill out the remaining
type-instantiation logic.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65649 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65641 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
nicely sugared type that shows how the user wrote the actual
specialization. This sugared type won't actually show up until we
start doing instantiations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65577 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
|
|
decls. Test and document the semantic location of class template
specialization definitions that occur within a scope enclosing the
scope of the class template.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65478 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
specializations. In particular:
- Make sure class template specializations have a "template<>"
header, and complain if they don't.
- Make sure class template specializations are declared/defined
within a valid context. (e.g., you can't declare a specialization
std::vector<MyType> in the global namespace).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65476 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
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@65169 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
(as GCC does), except when we've performed overload resolution and
found an unavailable function: in this case, we actually error.
Merge the checking of unavailable functions with the checking for
deprecated functions. This unifies a bit of code, and makes sure that
we're checking for unavailable functions in the right places. Also,
this check can cause an error. We may, eventually, want an option to
make "unavailable" warnings into errors.
Implement much of the logic needed for C++0x deleted functions, which
are effectively the same as "unavailable" functions (but always cause
an error when referenced). However, we don't have the syntax to
specify deleted functions yet :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64955 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
|
|
CXXRecordDecl that is used to represent class template
specializations. These are canonical declarations that can refer to
either an actual class template specialization in the code, e.g.,
template<> class vector<bool> { };
or to a template instantiation. However, neither of these features is
actually implemented yet, so really we're just using (and uniqing) the
declarations to make sure that, e.g., A<int> is a different type from
A<float>. Note that we carefully distinguish between what the user
wrote in the source code (e.g., "A<FLOAT>") and the semantic entity it
represents (e.g., "A<float, int>"); the former is in the sugared Type,
the latter is an actual Decl.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64716 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64337 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64321 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
for non-external names whose address becomes the template
argument. This completes C++ [temp.arg.nontype]p1.
Note that our interpretation of C++ [temp.arg.nontype]p1b3 differs
from EDG's interpretation (we're stricter, and GCC agrees with
us). They're opening a core issue about the matter.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64317 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64313 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Sema to ASTContext.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64312 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template specialization (e.g., std::vector<int> would now be
well-formed, since it relies on a default argument for the Allocator
template parameter).
This is much less interesting than one might expect, since (1) we're
not actually using the default arguments for anything important, such
as naming an actual Decl, and (2) we'll often need to instantiate the
default arguments to check their well-formedness. The real fun will
come later.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64310 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Rename Sema::hasSameUnqualifiedType to QualType::isSameIgnoringQalifiers
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64307 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
pointer-to-member-data non-type template parameters. Also, get
consistent about what it means to returned a bool from
CheckTemplateArgument.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64305 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
non-type template parameters that are references to functions or
pointers to member functions. Did a little bit of refactoring so that
these two cases, along with the handling of non-type template
parameters that are pointers to functions, are handled by the same
path.
Also, tweaked FixOverloadedFunctionReference to cope with member
function pointers. This is a necessary step for getting all of the fun
member pointer conversions working outside of template arguments, too.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64277 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template parameters that have reference type. Effectively, we're doing
a very limited form of reference binding here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64270 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
non-type template parameters of pointer-to-object and
pointer-to-function type. The most fun part of this is the use of
overload resolution to pick a function from the set of overloaded
functions that comes in as a template argument.
Also, fixed two minor bugs in this area:
- We were allowing non-type template parameters of type pointer to
void.
- We weren't patching up an expression that refers to an overloaded
function set via "&f" properly.
We're still not performing complete checking of the expression to be
sure that it is referring to an object or function with external
linkage (C++ [temp.arg.nontype]p1).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64266 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
integral or enumeration type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64256 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
arguments. This commit covers checking and merging default template
arguments from previous declarations, but it does not cover the actual
use of default template arguments when naming class template
specializations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64229 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64223 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
disambiguation contexts, so that we properly parse template arguments
such as
A<int()>
as type-ids rather than as expressions. Since this can be confusing
(especially when the template parameter is a non-type template
parameter), we try to give a friendly error message.
Almost, eliminate a redundant error message (that should have been a
note) and add some ultra-basic checks for non-type template
arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64189 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template parameters.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64188 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template parameters when performing semantic analysis of a template-id
naming a class template specialization.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64185 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
representation for template arguments. Also simplifies the interface
for ActOnClassTemplateSpecialization and eliminates some annoying
allocations of TemplateArgs.
My attempt at smart pointers for template arguments lists is
relatively lame. We can improve it once we're sure that we have the
right representation for template arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64154 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
to a class template. For example, the template-id 'vector<int>' now
has a nice, sugary type in the type system. What we can do now:
- Parse template-ids like 'vector<int>' (where 'vector' names a
class template) and form proper types for them in the type system.
- Parse icky template-ids like 'A<5>' and 'A<(5 > 0)>' properly,
using (sadly) a bool in the parser to tell it whether '>' should
be treated as an operator or not.
This is a baby-step, with major problems and limitations:
- There are currently two ways that we handle template arguments
(whether they are types or expressions). These will be merged, and,
most likely, TemplateArg will disappear.
- We don't have any notion of the declaration of class template
specializations or of template instantiations, so all template-ids
are fancy names for 'int' :)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@64153 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
redeclarations. For example, checks that a class template
redeclaration has the same template parameters as previous
declarations.
Detangled class-template checking from ActOnTag, whose logic was
getting rather convoluted because it tried to handle C, C++, and C++
template semantics in one shot.
Made some inroads toward eliminating extraneous "declaration does not
declare anything" errors by adding an "error" type specifier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63973 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63750 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Changes Lookup*Name functions to return NamedDecls, instead of
Decls. Unfortunately my recent statement that it will simplify lot of
code, was not quite right, but it simplifies some...
- Makes MergeLookupResult SmallPtrSet instead of vector, following
Douglas suggestions.
- Adds %qN format for printing qualified names to Diagnostic.
- Avoids searching for using-directives in Scopes, which are not
DeclScope, during unqualified name lookup.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63739 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
LookupName et al. Instead, use an enum and a bool to describe its
contents.
Optimized the C/Objective-C path through LookupName, eliminating any
unnecessarily C++isms. Simplify IdentifierResolver::iterator, removing
some code and arguments that are no longer used.
Eliminated LookupDeclInScope/LookupDeclInContext, moving all callers
over to LookupName, LookupQualifiedName, or LookupParsedName, as
appropriate.
All together, I'm seeing a 0.2% speedup on Cocoa.h with PTH and
-disable-free. Plus, we're down to three name-lookup routines.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63354 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
LookupDeclInContext().
The previous interface was very confusing. This is much more explicit, which will be easier to understand/optimize/convert.
The plan is to eventually deprecate both of these functions. For now, I'm focused on performance.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@63256 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
actually do anything with the template arguments, but they'll be used to create template declarations
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61413 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
become useful or correct until we (1) parse template arguments
correctly, (2) have some way to turn template-ids into types,
declarators, etc., and (3) have a real representation of templates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@61208 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
belongs
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@60708 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
expressions, and value-dependent expressions. This permits us to parse
some template definitions.
This is not a complete solution; we're missing type- and
value-dependent computations for most of the expression types, and
we're missing checks for dependent types and type-dependent
expressions throughout Sema.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@60615 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
parameters, with some semantic analysis:
- Template parameters are introduced into template parameter scope
- Complain about template parameter shadowing (except in Microsoft mode)
Note that we leak template parameter declarations like crazy, a
problem we'll remedy once we actually create proper declarations for
templates.
Next up: dependent types and value-dependent/type-dependent
expressions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@60597 91177308-0d34-0410-b5e6-96231b3b80d8
|
