walks through DeclContexts properly, and prints more of the
information available in the AST. The functionality is still available
via -ast-print, -ast-dump, etc., and also via the new member functions
Decl::dump() and Decl::print().
llvm-svn: 72597
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.
llvm-svn: 72590
instantiation of tags local to member functions of class templates
(and, eventually, function templates) works when the tag is defined as
part of the decl-specifier-seq, e.g.,
struct S { T x, y; } s1;
Also, make sure that we don't try to default-initialize a dependent
type.
llvm-svn: 72568
specifier resulted in the creation of a new TagDecl node, which
happens either when the tag specifier was a definition or when the tag
specifier was the first declaration of that tag type. This information
has several uses, the first of which is implemented in this commit:
1) In C++, one is not allowed to define tag types within a type
specifier (e.g., static_cast<struct S { int x; } *>(0) is
ill-formed) or within the result or parameter types of a
function. We now diagnose this.
2) We can extend DeclGroups to contain information about any tags
that are declared/defined within the declaration specifiers of a
variable, e.g.,
struct Point { int x, y, z; } p;
This will help improve AST printing and template instantiation,
among other things.
3) For C99, we can keep track of whether a tag type is defined
within the type of a parameter, to properly cope with cases like,
e.g.,
int bar(struct T2 { int x; } y) {
struct T2 z;
}
We can also do similar things wherever there is a type specifier,
e.g., to keep track of where the definition of S occurs in this
legal C99 code:
(struct S { int x, y; } *)0
llvm-svn: 72555
given DeclContext is dependent on type parameters. Use this to
properly determine whether a TagDecl is dependent; previously, we were
missing the case where the TagDecl is a local class of a member
function of a class template (phew!).
Also, make sure that, when we instantiate declarations within a member
function of a class template (or a function template, eventually),
that we add those declarations to the "instantiated locals" map so
that they can be found when instantiating declaration references.
Unfortunately, I was not able to write a useful test for this change,
although the assert() that fires when uncommenting the FIXME'd line in
test/SemaTemplate/instantiate-declref.cpp tells the "experienced user"
that we're now doing the right thing.
llvm-svn: 72526
parser. Rather than placing all of the delayed member function
declarations and inline definitions into a single bucket corresponding
to the top-level class, we instead mirror the nesting structure of the
nested classes and place the delayed member functions into their
appropriate place. Then, when we actually parse the delayed member
function declarations, set up the scope stack the same way as it was
when we originally saw the declaration, so that we can find, e.g.,
template parameters that are in scope.
llvm-svn: 72502
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.
llvm-svn: 72486
within a template now have a link back to the enumeration from which
they were instantiated. This means that we can now find the
instantiation of an anonymous enumeration.
llvm-svn: 72482
references. There are several smallish fixes here:
- Make sure we look through template parameter scope when
determining whether we're parsing a nested class (or nested class
*template*). This makes sure that we delay parsing the bodies of
inline member functions until after we're out of the outermost
class (template) scope.
- Since the bodies of member functions are always parsed
"out-of-line", even when they were declared in-line, teach
unqualified name lookup to look into the (semantic) parents.
- Use the new InstantiateDeclRef to handle the instantiation of a
reference to a declaration (in DeclRefExpr), which drastically
simplifies template instantiation for DeclRefExprs.
- When we're instantiating a ParmVarDecl, it must be in the current
instantiation scope, so only look there.
Also, remove the #if 0's and FIXME's from the dynarray example, which
now compiles and executes thanks to Anders and Eli.
llvm-svn: 72481
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();
llvm-svn: 72461
an integral constant expression, maintain a cache of the value and the
is-an-ICE flag within the VarDecl itself. This eliminates
exponential-time behavior of the Fibonacci template metaprogram.
llvm-svn: 72428
argument. This avoids the argument from being silenced when the argument is
the NULL macro, which is defined in a system header. This also makes the output
a bit nicer, e.g.:
t.c:8:3: warning: null passed to a callee which requires a non-null argument
func1(NULL, cp2, i1);
^ ~~~~
vs something like:
t.c:8:10: warning: argument is null where non-null is required
func1(NULL, cp2, i1);
^
llvm-svn: 72393
expressions. We are now missing template instantiation logic for only
three classes of expressions:
- Blocks-related expressions (BlockExpr, BlockDeclRefExpr)
- C++ default argument expressions
- Objective-C expressions
Additionally, our handling of DeclRefExpr is still quite poor, since
it cannot handle references to many kinds of declarations.
As part of this change, converted the TemplateExprInstantiator to use
iteration through all of the expressions via clang/AST/StmtNodes.def,
ensuring that we don't forget to add template instantiation logic for
any new expression node kinds.
llvm-svn: 72303
expressions. This change introduces another AST node,
CXXUnresolvedMemberExpr, that captures member references (x->m, x.m)
when the base of the expression (the "x") is type-dependent, and we
therefore cannot resolve the member reference yet.
Note that our parsing of member references for C++ is still quite
poor, e.g., we don't handle x->Base::m or x->operator int.
llvm-svn: 72281
and objects of this class are derived from 'NSProxy'.
Under such conditions, which means that every method possible is
implemented in the class, we should not issue "Method definition not found"
warnings.
llvm-svn: 72267
can. Also, delay semantic analysis of initialization for
value-dependent as well as type-dependent expressions, since we can't
always properly type-check a value-dependent expression.
llvm-svn: 72233
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.
llvm-svn: 72214
llvm::SmallVector that owns all of the AST nodes inside of it. This
RAII class is used to ensure proper destruction of AST nodes when
template instantiation fails.
llvm-svn: 72186
temporaries are generated for some object-constructing expressions in
templates that are not type-dependent.
Also, be sure to introduce the variable from a CXXConditionDeclExpr
into the set of instantiated local variables.
llvm-svn: 72185
describe the construction of a value of a given type using function
syntax, e.g.,
T(a1, a2, ..., aN)
when the type or any of its arguments are type-dependent. In this
case, we don't know what kind of type-construction this will be: it
might construct a temporary of type 'T' (which might be a class or
non-class type) or might perform a conversion to type 'T'. Also,
implement printing of and template instantiation for this new
expression type. Due to the change in Sema::ActOnCXXTypeConstructExpr,
our existing tests cover template instantiation of this new expression
node.
llvm-svn: 72176
statement was using an rvalue reference during the template
definition. However, template instantiations based on an lvalue
reference type are well-formed, so we delay checking of these property
until template instantiation time.
llvm-svn: 72041
kinds of statements (in the instantiation logic). No functionality
change, but now we'll get linker errors if we add a statement but
forget to introduce its instantiation logic.
llvm-svn: 72031
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.
llvm-svn: 72015
alternatives, but please correct me if I'm wrong.
I eventually plan to assert in mergeTypes that we aren't in C++ mode
because composite types are fundamentally not a part of C++. The
remaining callers for code in the regression tests are
Sema::WarnConflictingTypedMethods and CodeGenFunction::EmitFunctionProlog;
I'm not quite sure what the correct approach is for those callers.
llvm-svn: 71946
This patch isn't quite ideal in that it eliminates the warning for
constructs like "int a = {1};", where the braces are in fact redundant.
However, that would have required a bunch of refactoring, and it's
much less likely to cause confusion compared to redundant nested braces.
llvm-svn: 71939
constructors and destructors. This is a requirement of
DeclarationNameTable::getCXXSpecialName that we weren't assert()'ing,
so it should have been caught much earlier :(
Big thanks to Anders for the test case.
llvm-svn: 71895
- Skip semantic analysis of the "if" condition if it is type-dependent.
- Added the location of the "else" keyword into IfStmt, so that we can
provide it for type-checking after template instantiation.
llvm-svn: 71875
template to the FunctionDecls from which they were instantiated. This
is a necessary first step to support instantiation of the definitions
of such functions, but by itself does essentially nothing.
llvm-svn: 71792
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.
llvm-svn: 71756
cf_returns_retained. Currently this attribute can now be applied to any
Objective-C method or C function that returns a pointer or Objective-C object
type.
Modify the tablegen definition of diagnostic 'warn_attribute_wrong_decl_type' to
expect that the diagnostics infrastructure will add quotes around the attribute
name when appropriate. Alonq with this change, I modified the places where this
warning is issued to passed the attribute's IdentifierInfo* instead of having a
hard-coded C constant string.
llvm-svn: 71718
of class members (recursively). Only member classes are actually
instantiated; the instantiation logic for member functions and
variables are just stubs.
llvm-svn: 71713
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.
llvm-svn: 71689
It seems dubious to me that isIntegerType() returns true for
vectors of integers, but not complex integers. This should
probably be rethought, I'll file a bugzilla.
llvm-svn: 71640
don't support. While it would be nice to support this eventually,
this form is not common at all (just seen in gcc testsuite) and
it might be better to model vector_size as a type attribute anyway.
For now just emit a nice error on it.
llvm-svn: 71633
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).
llvm-svn: 71613
template class X<int>;
This also cleans up the propagation of template information through
declaration parsing, which is used to improve some diagnostics.
llvm-svn: 71608
Per the FIXME, it might be interesting to track whether the inline keyword
was also used on the method, but for now we don't do this. Testcase pending.
llvm-svn: 71589
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.
llvm-svn: 71517
specialization" within a C++ template, and permit name lookup into the
current instantiation. For example, given:
template<typename T, typename U>
struct X {
typedef T type;
X* x1; // current instantiation
X<T, U> *x2; // current instantiation
X<U, T> *x3; // not current instantiation
::X<type, U> *x4; // current instantiation
X<typename X<type, U>::type, U>: *x5; // current instantiation
};
llvm-svn: 71471
template. The injected-class-name is either a type or a template,
depending on whether a '<' follows it. As a type, the
injected-class-name's template argument list contains its template
parameters in declaration order.
As part of this, add logic for canonicalizing declarations, and be
sure to canonicalize declarations used in template names and template
arguments.
A TagType is dependent if the declaration it references is dependent.
I'm not happy about the rather complicated protocol needed to use
ASTContext::getTemplateSpecializationType.
llvm-svn: 71408
of the underlying _N builtin, not the the type of the pointee of the
actual type. This ensures that atomics involving pointers end up
using the correct integer type when they are resolved, avoiding
aborts in codegen.
llvm-svn: 71218
semantic rules that gcc and icc use. This implements the variadic
and concrete versions as builtins and has sema do the
disambiguation. There are probably a bunch of details to finish up
but this seems like a large monotonic step forward :)
llvm-svn: 71212
Anders Carlsson