| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 67818
|
|
|
|
|
|
| |
intended functionality change.
llvm-svn: 67725
|
|
|
|
|
|
| |
original declaration.
llvm-svn: 67722
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specializations can be treated as a template. Finally, we can parse
and process the first implementation of Fibonacci I wrote!
Note that this code does not handle all of the cases where
injected-class-names can be treated as templates. In particular,
there's an ambiguity case that we should be able to handle (but
can't), e.g.,
template <class T> struct Base { };
template <class T> struct Derived : Base<int>, Base<char> {
typename Derived::Base b; // error: ambiguous
typename Derived::Base<double> d; // OK
};
llvm-svn: 67720
|
|
|
|
|
|
|
|
| |
a C++ record decl.
Also, fix fallout from the change.
llvm-svn: 67717
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
templates, including in-class initializers. For example:
template<typename T, T Divisor>
class X {
public:
static const T value = 10 / Divisor;
};
instantiated with, e.g.,
X<int, 5>::value
to get the value '2'.
llvm-svn: 67715
|
|
|
|
| |
llvm-svn: 67710
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 67707
|
|
|
|
| |
llvm-svn: 67687
|
|
|
|
|
|
|
| |
incomplete types. RequireCompleteType is needed when the type may be
completed by instantiating a template.
llvm-svn: 67643
|
|
|
|
|
|
|
|
|
|
|
|
| |
class C {
void g(C c);
virtual void f() = 0;
};
In this case, C is not known to be abstract when doing semantic analysis on g. This is done by recursively traversing the abstract class and checking the types of member functions.
llvm-svn: 67594
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a class template. At present, we can only instantiation normal
methods, but not constructors, destructors, or conversion operators.
As ever, this contains a bit of refactoring in Sema's type-checking. In
particular:
- Split ActOnFunctionDeclarator into ActOnFunctionDeclarator
(handling the declarator itself) and CheckFunctionDeclaration
(checking for the the function declaration), the latter of which
is also used by template instantiation.
- We were performing the adjustment of function parameter types in
three places; collect those into a single new routine.
- When the type of a parameter is adjusted, allocate an
OriginalParmVarDecl to keep track of the type as it was written.
- Eliminate a redundant check for out-of-line declarations of member
functions; hide more C++-specific checks on function declarations
behind if(getLangOptions().CPlusPlus).
llvm-svn: 67575
|
|
|
|
|
|
| |
make sure to check parameter types before they decay.
llvm-svn: 67550
|
|
|
|
| |
llvm-svn: 67542
|
|
|
|
|
|
|
|
| |
library function, accept this declaration and pretend that we do not
know that this is a library function. autoconf depends on this
(broken) behavior.
llvm-svn: 67541
|
|
|
|
|
|
| |
prototype. Thanks Eli!
llvm-svn: 67533
|
|
|
|
| |
llvm-svn: 67530
|
|
|
|
| |
llvm-svn: 67476
|
|
|
|
|
|
| |
used for the __is_abstract type trait.
llvm-svn: 67461
|
|
|
|
|
|
| |
there is a previous declaration marked "static". This fixes PR3645.
llvm-svn: 67336
|
|
|
|
| |
llvm-svn: 67316
|
|
|
|
|
|
|
|
|
|
| |
F f;
where F is a typedef of a function type, then the function "f" has a
prototype. This is a slight tweak to Chris's suggested fix in
PR3817. Fixes PR3817 and PR3840.
llvm-svn: 67313
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 67308
|
|
|
|
|
|
|
|
|
|
|
| |
specialization names. This way, we keep track of sugared types like
std::vector<Real>
I believe we are now using QualifiedNameTypes everywhere we can. Next
step: QualifiedDeclRefExprs.
llvm-svn: 67268
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 67265
|
|
|
|
|
|
|
|
|
|
| |
Type pointer. This allows our nested-name-specifiers to retain more
information about the actual spelling (e.g., which typedef did the
user name, or what exact template arguments were used in the
template-id?). It will also allow us to have dependent
nested-name-specifiers that don't map to any DeclContext.
llvm-svn: 67140
|
|
|
|
|
|
| |
no functionality change.
llvm-svn: 67128
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 67092
|
|
|
|
| |
llvm-svn: 67045
|
|
|
|
|
|
|
|
| |
http://llvm.org/viewvc/llvm-project?view=rev&revision=65694 and http://llvm.org/viewvc/llvm-project?view=rev&revision=66741).
Will replace with something better today...
llvm-svn: 66893
|
|
|
|
| |
llvm-svn: 66835
|
|
|
|
|
|
|
|
| |
be CompoundStmts. I think this is a valid assumption, and felt that the API
should reflect it. Others please validate this assumption to make sure I didn't
break anything.
llvm-svn: 66814
|
|
|
|
|
|
|
|
|
| |
class members to the corresponding in-class declaration.
Diagnose the erroneous use of 'static' on out-of-line definitions of
class members.
llvm-svn: 66740
|
|
|
|
|
|
| |
general routines. This is a step toward separating the checking logic from Declarators, which in turn is required for template instantiation.
llvm-svn: 66734
|
|
|
|
|
|
| |
and that the aggregate and POD flags for an instantiated class template are updated based on instantiation of a FieldDecl
llvm-svn: 66701
|
|
|
|
| |
llvm-svn: 66696
|
|
|
|
|
|
|
| |
for FieldDecls so that the parser and the template instantiation make
use of the same semantic checking module.
llvm-svn: 66685
|
|
|
|
|
|
|
|
|
| |
template. More importantly, start to sort out the issues regarding
complete types and nested-name-specifiers, especially the question of:
when do we instantiate a class template specialization that occurs to
the left of a '::' in a nested-name-specifier?
llvm-svn: 66662
|
|
|
|
|
|
|
|
|
| |
translation unit.
Thread the various declarations of variables via
VarDecl::getPreviousDeclaration.
llvm-svn: 66601
|
|
|
|
|
|
|
|
|
|
|
| |
definitions. We were rejecting tentative definitions of incomplete
(which is bad), and now we don't.
This fix is partial because we don't do the end-of-translation-unit
initialization for tentative definitions that don't ever have any
initializers specified.
llvm-svn: 66584
|
|
|
|
| |
llvm-svn: 66549
|
|
|
|
|
|
| |
documentation to reflect the fact that we can instantiate templates here
llvm-svn: 66421
|
|
|
|
|
|
|
| |
struct to an extension warning to match the behavior of GNU C, which
addresses the Sema part of PR3671.
llvm-svn: 66308
|
|
|
|
|
|
| |
anonymous struct/union declaration outside of a struct or union in C
llvm-svn: 66303
|
|
|
|
|
|
|
|
| |
prototype of the same function, where the promoted parameter types in
the K&R definition are not compatible with the types in the
prototype. Fixes PR2821.
llvm-svn: 66301
|
|
|
|
| |
llvm-svn: 66286
|
|
|
|
|
|
| |
C and C++. Fixes PR3688.
llvm-svn: 66282
|
|
|
|
| |
llvm-svn: 66213
|
|
|
|
|
|
| |
more consistently.
llvm-svn: 66210
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
like:
Stack dump:
0. t.c:5:10: in compound statement ('{}')
1. t.c:3:12: in compound statement ('{}')
2. t.c:3:12: parsing function body 'foo'
3. clang t.c
Abort
llvm-svn: 66118
|