| Age | Commit message (Collapse) | Author |
|---|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73232 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
partial specialization, substitute those template arguments back into
the template arguments of the class template partial specialization to
see if the results still match the original template arguments.
This code is more general than it needs to be, since we don't yet
diagnose C++ [temp.class.spec]p9. However, it's likely to be needed
for function templates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73196 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73176 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
Also, introduced some of the framework for performing instantiation as
part of template argument deduction.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73175 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
T::*) and implement template instantiation for member pointer types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@73151 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
- Once we have deduced template arguments for a class template partial
specialization, we use exactly those template arguments for instantiating
the definition of the class template partial specialization.
- Added template argument deduction for non-type template parameters.
- Added template argument deduction for dependently-sized array types.
With these changes, we can now implement, e.g., the remove_reference
type trait. Also, Daniel's Ackermann template metaprogram now compiles
properly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72909 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
deductions of the same template parameter are equivalent. This allows
us to implement the is_same type trait (!).
Also, move template argument deduction into its own file and update a
few build systems with this change (grrrr).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72819 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
we have the basics of declaring and storing class template partial
specializations, matching class template partial specializations at
instantiation time via (limited) template argument deduction, and
using the class template partial specialization's pattern for
instantiation.
This patch is enough to make a simple is_pointer type trait work, but
not much else.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72662 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
printing logic to help customize the output. For now, we use this
rather than a special flag to suppress the "struct" when printing
"struct X" and to print the Boolean type as "bool" in C++ but "_Bool"
in C.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72590 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template instantiation. This helps reduce our stack footprint when
performing deep template instantiations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72582 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
declaration references. The key realization is that dependent Decls,
which actually require instantiation, can only refer to the current
instantiation or members thereof. And, since the current context
during instantiation contains all of those members of the current
instantiation, we can simply find the real instantiate that matches up
with the "current instantiation" template.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72486 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
instantiation of a declaration from the template version (or version
that lives in a template) and a given set of template arguments. This
needs much, much more testing, but it suffices for simple examples
like
typedef T* iterator;
iterator begin();
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72461 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72440 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72433 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72210 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template, introduce that member function into the template
instantiation stack. Also, add diagnostics showing the member function
within the instantiation stack and clean up the qualified-name
printing so that we get something like:
note: in instantiation of member function 'Switch1<int, 2, 2>::f'
requested here
in the template instantiation backtrace.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@72015 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71936 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
functions of class templates. Only compound statements and expression
statements are currently implemented.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71814 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template<typename T>
struct X {
struct Inner;
};
template struct X<int>::Inner;
This change is larger than it looks because it also fixes some
a problem with nested-name-specifiers and tags. We weren't requiring
the DeclContext associated with the scope specifier of a tag to be
complete. Therefore, when looking for something like "struct
X<int>::Inner", we weren't instantiating X<int>.
This, naturally, uncovered a problem with member pointers, where we
were requiring the left-hand side of a member pointer access
expression (e.g., x->*) to be a complete type. However, this is wrong:
the semantics of this expression does not require a complete type (EDG
agrees).
Stuart vouched for me. Blame him.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71756 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
of class members (recursively). Only member classes are actually
instantiated; the instantiation logic for member functions and
variables are just stubs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71713 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
templates. In particular:
- An explicit instantiation can follow an implicit instantiation (we
were improperly diagnosing this as an error, previously).
- In C++0x, an explicit instantiation that follows an explicit
specialization of the same template specialization is ignored. In
C++98, we just emit an extension warning.
- In C++0x, an explicit instantiation must be in a namespace
enclosing the original template. C++98 has no such requirement.
Also, fixed a longstanding FIXME regarding the integral type that is
used for the size of a constant array type when it is being instantiated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71689 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
still aren't instantiating the definitions of class template members,
and core issues 275 and 259 will both affect the checking that we do
for explicit instantiations (but are not yet implemented).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71613 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
TemplateArgumentList. This avoids the need to pass around
pointer/length pairs of template arguments lists, and will eventually
make it easier to introduce member templates and variadic templates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@71517 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70567 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@70566 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@69783 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
No functionality change (really).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68726 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
specifiers that terminate in a simple-template-id, e.g.,
typename MetaFun::template apply<T1, T2>
Also, implement template instantiation for dependent
nested-name-specifiers that involve unresolved identifiers, e.g.,
typename T::type::type
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68166 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68140 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
template template parameters and dependent template names. For
example, the oft-mentioned
typename MetaFun::template apply<T1, T2>::type
can now be instantiated, with the appropriate name lookup for "apply".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@68128 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
|
|
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
|
|
instantiation for C++ typename-specifiers such as
typename T::type
The parsing of typename-specifiers is relatively easy thanks to
annotation tokens. When we see the "typename", we parse the
typename-specifier and produce a typename annotation token. There are
only a few places where we need to handle this. We currently parse the
typename-specifier form that terminates in an identifier, but not the
simple-template-id form, e.g.,
typename T::template apply<U, V>
Parsing of nested-name-specifiers has a similar problem, since at this
point we don't have any representation of a class template
specialization whose template-name is unknown.
Semantic analysis is only partially complete, with some support for
template instantiation that works for simple examples.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67875 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
uniqued representation that should both save some memory and make it
far easier to properly build canonical types for types involving
dependent nested-name-specifiers, e.g., "typename T::Nested::type".
This approach will greatly simplify the representation of
CXXScopeSpec. That'll be next.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67799 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67708 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
the declarations of member classes are instantiated when the owning
class template is instantiated. The definitions of such member classes
are instantiated when a complete type is required.
This change also introduces the injected-class-name into a class
template specialization.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67707 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67660 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
variant of DiagnosticBuilder that emits the template instantiation
backtrace when needed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67413 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
dependent qualified-ids such as
Fibonacci<N - 1>::value
where N is a template parameter. These references are "unresolved"
because the name is dependent and, therefore, cannot be resolved to a
declaration node (as we would do for a DeclRefExpr or
QualifiedDeclRefExpr). UnresolvedDeclRefExprs instantiate to
DeclRefExprs, QualifiedDeclRefExprs, etc.
Also, be a bit more careful about keeping only a single set of
specializations for a class template, and instantiating from the
definition of that template rather than a previous declaration. In
general, we need a better solution for this for all TagDecls, because
it's too easy to accidentally look at a declaration that isn't the
definition.
We can now process a simple Fibonacci computation described as a
template metaprogram.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67308 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
qualified name, e.g.,
foo::x
so that we retain the nested-name-specifier as written in the source
code and can reproduce that qualified name when printing the types
back (e.g., in diagnostics). This is PR3493, which won't be complete
until finished the other tasks mentioned near the end of this commit.
The parser's representation of nested-name-specifiers, CXXScopeSpec,
is now a bit fatter, because it needs to contain the scopes that
precede each '::' and keep track of whether the global scoping
operator '::' was at the beginning. For example, we need to keep track
of the leading '::', 'foo', and 'bar' in
::foo::bar::x
The Action's CXXScopeTy * is no longer a DeclContext *. It's now the
opaque version of the new NestedNameSpecifier, which contains a single
component of a nested-name-specifier (either a DeclContext * or a Type
*, bitmangled).
The new sugar type QualifiedNameType composes a sequence of
NestedNameSpecifiers with a representation of the type we're actually
referring to. At present, we only build QualifiedNameType nodes within
Sema::getTypeName. This will be extended to other type-constructing
actions (e.g., ActOnClassTemplateId).
Also on the way: QualifiedDeclRefExprs will also store a sequence of
NestedNameSpecifiers, so that we can print out the property
nested-name-specifier. I expect to also use this for handling
dependent names like Fibonacci<I - 1>::value.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67265 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
addresses the second part of review feedback.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67259 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
non-typedependent expression)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67226 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67216 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67148 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67145 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
cleaner visitor framework.
Added a visitor for declarations, which is quite similar to the
visitor for statatements.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67104 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
quite as great as it sounds, because, while we can refer to the
enumerator values outside the template, e.g.,
adder<long, 3, 4>::value
we can't yet refer to them with dependent names, so no Fibonacci
(yet).
InstantiateClassTemplateSpecialization is getting messy; next commit
will put it into a less-ugly state.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67092 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67063 91177308-0d34-0410-b5e6-96231b3b80d8
|
|
IntegerLiterals during instantiation when we should be creating either
a boolean literal (CXXBoolLiteralExpr) or a character literal
(CharacterLiteral).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@67061 91177308-0d34-0410-b5e6-96231b3b80d8
|
