| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 71886
|
|
|
|
| |
llvm-svn: 71885
|
|
|
|
| |
llvm-svn: 71878
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
| |
llvm-svn: 71872
|
|
|
|
|
|
| |
instantiating the definition of a function from a template.
llvm-svn: 71869
|
|
|
|
| |
llvm-svn: 71825
|
|
|
|
| |
llvm-svn: 71823
|
|
|
|
| |
llvm-svn: 71822
|
|
|
|
| |
llvm-svn: 71818
|
|
|
|
|
|
|
| |
method is a qualified id which conforms to the matching type
of its method declaration.
llvm-svn: 71817
|
|
|
|
| |
llvm-svn: 71816
|
|
|
|
|
|
|
| |
functions of class templates. Only compound statements and expression
statements are currently implemented.
llvm-svn: 71814
|
|
|
|
| |
llvm-svn: 71802
|
|
|
|
| |
llvm-svn: 71800
|
|
|
|
|
|
| |
from variable declarations that occur within templates to their instantiated counterparts
llvm-svn: 71799
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 71790
|
|
|
|
| |
llvm-svn: 71788
|
|
|
|
| |
llvm-svn: 71786
|
|
|
|
|
|
| |
all.
llvm-svn: 71780
|
|
|
|
|
|
| |
with sentinel attribute.
llvm-svn: 71778
|
|
|
|
|
|
|
| |
declared as a "class", or vice-versa. This warning is under the
control of -Wmismatched-tags, which is off by default.
llvm-svn: 71773
|
|
|
|
|
|
| |
don't check covariance but that's next.
llvm-svn: 71759
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
dispatch arguments which have sentinel attribute.
llvm-svn: 71737
|
|
|
|
| |
llvm-svn: 71721
|
|
|
|
|
|
| |
diagnostic IDs.
llvm-svn: 71720
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
-faccess-control option. When we have better support for it, we can enable it by default again.
llvm-svn: 71706
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
message dispatches (and function calls later). No change in
functionality.
llvm-svn: 71683
|
|
|
|
|
|
|
|
|
| |
NumArgs && "Arg access out of range!").
For format string checking, only check the type of the format
specifier for non-vararg functions.
llvm-svn: 71672
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
rdar://6880104
llvm-svn: 71639
|
|
|
|
|
|
| |
now until someone does it right
llvm-svn: 71638
|
|
|
|
|
|
| |
rdar://6880573
llvm-svn: 71636
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
extension.
This implements rdar://6880449 - improve diagnostic for usage of "global register variable" GCC extension
llvm-svn: 71599
|
|
|
|
|
|
| |
declarations.
llvm-svn: 71597
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 71489
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
declaration can now be NULL. Use cast_or_null appropriately
llvm-svn: 71412
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 71405
|