| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Work in progress...
llvm-svn: 71908
|
| |
|
|
| |
llvm-svn: 71907
|
| |
|
|
| |
llvm-svn: 71903
|
| |
|
|
| |
llvm-svn: 71901
|
| |
|
|
| |
llvm-svn: 71899
|
| |
|
|
| |
llvm-svn: 71896
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
No change in functionality.
llvm-svn: 71894
|
| |
|
|
| |
llvm-svn: 71889
|
| |
|
|
|
|
| |
blocks and function pointers.
llvm-svn: 71888
|
| |
|
|
| |
llvm-svn: 71887
|
| |
|
|
| |
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
|