| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 91016
|
|
|
|
| |
llvm-svn: 91015
|
|
|
|
|
|
| |
(fixes radar 7457109).
llvm-svn: 90986
|
|
|
|
|
|
| |
This time with a fix to bail out when in a dependent context.
llvm-svn: 90730
|
|
|
|
| |
llvm-svn: 90729
|
|
|
|
|
|
| |
to fix it ATM.
llvm-svn: 90717
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
intended. On the first testcase in the bug, we now produce:
cxx-decl.cpp:12:2: error: unexpected ':' in nested name specifier
y:a a2;
^
::
instead of:
t.cc:8:1: error: C++ requires a type specifier for all declarations
x:a a2;
^
t.cc:8:2: error: invalid token after top level declarator
x:a a2;
^
;
t.cc:9:11: error: use of undeclared identifier 'a2'
x::a a3 = a2;
^
llvm-svn: 90713
|
|
|
|
|
|
|
|
|
|
|
| |
overloaded-operator resolution is wildly untested, but the parallel code for
methods seems to satisfy some trivial tests.
Also change some overload-resolution APIs to take a type instead of an expression,
which lets us avoid creating a spurious CXXThisExpr when resolving implicit
member accesses.
llvm-svn: 90410
|
|
|
|
| |
llvm-svn: 90071
|
|
|
|
| |
llvm-svn: 90069
|
|
|
|
|
|
| |
going away).
llvm-svn: 90066
|
|
|
|
|
|
|
| |
function names outside of templates - they'll probably cause some damage there as
they're largely untested.
llvm-svn: 90064
|
|
|
|
| |
llvm-svn: 90030
|
|
|
|
|
|
| |
DeclarationName can't handle them yet, so right now Parser just errors out on them.
llvm-svn: 90027
|
|
|
|
| |
llvm-svn: 89894
|
|
|
|
| |
llvm-svn: 89876
|
|
|
|
| |
llvm-svn: 89874
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following attributes are currently supported in C++0x attribute
lists (and in GNU ones as well):
- align() - semantics believed to be conformant to n3000, except for
redeclarations and what entities it may apply to
- final - semantics believed to be conformant to CWG issue 817's proposed
wording, except for redeclarations
- noreturn - semantics believed to be conformant to n3000, except for
redeclarations
- carries_dependency - currently ignored (this is an optimization hint)
llvm-svn: 89543
|
|
|
|
| |
llvm-svn: 89260
|
|
|
|
|
|
| |
use of pointer to data member.
llvm-svn: 89251
|
|
|
|
|
|
| |
clang-cc when they do.
llvm-svn: 89070
|
|
|
|
| |
llvm-svn: 88749
|
|
|
|
| |
llvm-svn: 86432
|
|
|
|
|
|
| |
- 'for i in $(find . -type f); do sed -e 's#\(RUN:.*[^ ]\) *&& *$#\1#g' $i | FileUpdate $i; done', for the curious.
llvm-svn: 86430
|
|
|
|
| |
llvm-svn: 86293
|
|
|
|
|
|
| |
(radar 7370882).
llvm-svn: 86291
|
|
|
|
|
|
|
|
| |
Conditional operands are next.
Fixes part of rdar://problem/7289584.
llvm-svn: 86083
|
|
|
|
|
|
|
|
| |
template<> struct foo<int> { ... };
where "foo" does not refer to a template. Fixes PR3844.
llvm-svn: 85616
|
|
|
|
| |
llvm-svn: 85236
|
|
|
|
|
|
| |
instead of crashing in code gen.
llvm-svn: 84968
|
|
|
|
| |
llvm-svn: 83945
|
|
|
|
|
|
|
|
|
|
|
| |
templates, and keep track of how those member classes were
instantiated or specialized.
Make sure that we don't try to instantiate an explicitly-specialized
member class of a class template, when that explicit specialization
was a declaration rather than a definition.
llvm-svn: 83547
|
|
|
|
|
|
|
|
|
| |
class templates. We now treat friend class templates much more like
normal class templates, except that they still get special name lookup
rules. Fixes PR5057 and eliminates a bunch of spurious diagnostics in
<iostream>.
llvm-svn: 82848
|
|
|
|
|
|
|
|
| |
member functions of class template specializations, and static data
members. The mechanics are (mostly) present, but the semantic analysis
is very weak.
llvm-svn: 82789
|
|
|
|
| |
llvm-svn: 81654
|
|
|
|
| |
llvm-svn: 81622
|
|
|
|
| |
llvm-svn: 81346
|
|
|
|
| |
llvm-svn: 79913
|
|
|
|
| |
llvm-svn: 79912
|
|
|
|
| |
llvm-svn: 78274
|
|
|
|
| |
llvm-svn: 77780
|
|
|
|
| |
llvm-svn: 77573
|
|
|
|
|
|
|
|
| |
regresses Clang extension conversions, like vectors, but allows conversions via constructors and conversion operators.
Add custom conversions to static_cast.
llvm-svn: 77076
|
|
|
|
|
|
|
|
|
|
| |
Something strange is going on here; this test randomly started failing after
unrelated changes to TestRunner.py (even though it runs the same
script).
Argiris or Doug, can one of you investigate?
llvm-svn: 77063
|
|
|
|
|
|
| |
being masked by previous bug.
llvm-svn: 76858
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
templates, e.g.,
template<typename T>
struct Outer {
struct Inner;
};
template<typename T>
struct Outer<T>::Inner {
// ...
};
Implementing this feature required some extensions to ActOnTag, which
now takes a set of template parameter lists, and is the precursor to
removing the ActOnClassTemplate function from the parser Action
interface. The reason for this approach is simple: the parser cannot
tell the difference between a class template definition and the
definition of a member of a class template; both have template
parameter lists, and semantic analysis determines what that template
parameter list means.
There is still some cleanup to do with ActOnTag and
ActOnClassTemplate. This commit provides the basic functionality we
need, however.
llvm-svn: 76820
|
|
|
|
|
|
|
| |
data members of class templates. We don't instantiate the definitions yet,
however.
llvm-svn: 76756
|
|
|
|
| |
llvm-svn: 76709
|
|
|
|
|
|
| |
out an error for a malformed __builtin_offsetof.
llvm-svn: 74388
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
templates.
For example, this now type-checks (but does not instantiate the body
of deref<int>):
template<typename T> T& deref(T* t) { return *t; }
void test(int *ip) {
int &ir = deref(ip);
}
Specific changes/additions:
* Template argument deduction from a call to a function template.
* Instantiation of a function template specializations (just the
declarations) from the template arguments deduced from a call.
* FunctionTemplateDecls are stored directly in declaration contexts
and found via name lookup (all forms), rather than finding the
FunctionDecl and then realizing it is a template. This is
responsible for most of the churn, since some of the core
declaration matching and lookup code assumes that all functions are
FunctionDecls.
llvm-svn: 74213
|