class C {
public:
static void foo2() { }
};
template <class T> class A {
public:
typedef C D;
};
template <class T> class B : public A<T> {
public:
void foo() { D::foo2(); }
};
Note that this won't work if the NestedNameSpecifier refers to a type.
This fixes 1 error when parsing the MSVC 2010 standard headers file with clang.
llvm-svn: 136203
that allocates an array of objects with a non-trivial destructor, be
sure to mark the destructor is "used". Fixes PR10480 /
<rdar://problem/9834317>.
llvm-svn: 136081
which is required given the current setup for template
argument deduction substitution validation, and add a test
case to make sure we don't break it in the future.
llvm-svn: 135262
template<typename T> struct S { } f() { return 0; }
This case now produces a missing ';' diagnostic, since that seems like a much more likely error than an attempt to declare a function or variable in addition to the class template.
Treat this
llvm-svn: 135195
were just punting on template argument deduction for a number of type
nodes. Most of them, obviously, didn't matter.
As a consequence of this, make extended vector types (via the
ext_vector_type attribute) actually work properly for several
important cases:
- If the attribute appears in a type-id (i.e, not attached to a
typedef), actually build a proper vector type
- Build ExtVectorType whenever the size is constant; previously, we
were building DependentSizedExtVectorType when the size was constant
but the type was dependent, which makes no sense at all.
- Teach template argument deduction to handle
ExtVectorType/DependentSizedExtVectorType.
llvm-svn: 133060
before the template parameters have acquired a proper context (e.g.,
because the enclosing context has yet to be built), provide empty
parameter lists for all outer template parameter scopes to inhibit any
substitution for those template parameters. Fixes PR9643 /
<rdar://problem/9251019>.
llvm-svn: 133055
- Move a test from test/SemaTemplate/instantiate-expr-3.cpp, it did not belong there
- Incomplete and abstract types are considered hard errors
llvm-svn: 132979
namespace set algorithm (re-)introduced. We may not have seen the 'std'
namespace, but we should still suggested associated namespaces. Easy
fix, but a bit annoying to test.
llvm-svn: 132744
Sema::RequireCompleteExprType() a bit more, setting the point of
instantiation if needed, and skipping explicit specializations entirely.
llvm-svn: 132547
of incomplete array type, attempt to complete the array type. This was
made much easier by Chandler's addition of RequireCompleteExprType(),
which I've tweaked (slightly) to improve the consistency of the
DeclRefExpr. Fixes PR7985.
llvm-svn: 132530
within class templates when they are necessary to complete the type of
the member. The canonical example is code like:
template <typename T> struct S {
static const int arr[];
static const int x;
static int f();
};
template <typename T> const int S<T>::arr[] = { 1, 2, 3 };
template <typename T> const int S<T>::x = sizeof(arr) / sizeof(arr[0]);
template <typename T> int S<T>::f() { return x; }
int x = S<int>::f();
We need to instantiate S<T>::arr's definition to pick up its initializer
and complete the array type. This involves new code to specially handle
completing the type of an expression where the type alone is
insufficient. It also requires *updating* the expression with the newly
completed type. Fortunately, all the other infrastructure is already in
Clang to do the instantiation, do the completion, and prune out the
unused bits of code that result from this instantiation.
This addresses the initial bug in PR10001, and will be a step to
fleshing out other cases where we need to work harder to complete an
expression's type. Who knew we still had missing C++03 "features"?
llvm-svn: 132172
also consider whether any of the parameter types (as written, prior to
decay) are dependent. Fixes PR9880 and <rdar://problem/9408413>.
llvm-svn: 131099
parameters on the floor in certain cases:
class X {
template <typename T> friend typename A<T>::Foo;
};
This was parsed as a *non* template friend declaration some how, and
received an ExtWarn. Fixing the parser to actually provide the template
parameters to the freestanding declaration parse triggers the code which
specifically looks for such constructs and hard errors on them.
Along the way, this prevents us from trying to instantiate constructs
like the above inside of a outer template. This is important as loosing
the template parameters means we don't have a well formed declaration
and template instantiation will be unable to rebuild the AST. That fixes
a crash in the GCC test suite.
llvm-svn: 130772
partial ordering of function templates, use a simple superset
relationship rather than the convertibility-implying
isMoreQualifiedThan/compatibilyIncludes relationship. Fixes partial
ordering between references and address-space-qualified references.
llvm-svn: 130612
in the classification of template names and using declarations. We now
properly typo-correct the leading identifiers in statements to types,
templates, values, etc. As an added bonus, this reduces the number of
lookups required for disambiguation.
llvm-svn: 130288
dealing with address-space- and GC-qualified pointers. Previously,
these qualifiers were being treated just like cvr-qualifiers (in some
cases) or were completely ignored, leading to uneven behavior. For
example, const_cast would allow conversion between pointers to
different address spaces.
The new semantics are fairly simple: reinterpret_cast can be used to
explicitly cast between pointers to different address spaces
(including adding/removing addresss spaces), while
static_cast/dynamic_cast/const_cast do not tolerate any changes in the
address space. C-style casts can add/remove/change address spaces
through the reinterpret_cast mechanism. Other non-CVR qualifiers
(e.g., Objective-C GC qualifiers) work similarly.
As part of this change, I tweaked the "casts away constness"
diagnostic to use the term "casts away qualifiers". The term
"constness" actually comes from the C++ standard, despite the fact
that removing "volatile" also falls under that category. In Clang, we
also have restrict, address spaces, ObjC GC attributes, etc., so the
more general "qualifiers" is clearer.
llvm-svn: 129583
The idea is that you can create a VarDecl with an unknown type, or a
FunctionDecl with an unknown return type, and it will still be valid to
access that object as long as you explicitly cast it at every use. I'm
still going back and forth about how I want to test this effectively, but
I wanted to go ahead and provide a skeletal implementation for the LLDB
folks' benefit and because it also improves some diagnostic goodness for
placeholder expressions.
llvm-svn: 129065
overload, so that we actually do the resolution for full expressions
and emit more consistent, useful diagnostics. Also fixes an IRGen
crasher, where Sema wouldn't diagnose a resolvable bound member
function template-id used in a full-expression (<rdar://problem/9108698>).
llvm-svn: 127747
to set the source-location information for the template arguments to
the *transformed* source-location information, not the original
source-location information. Fixes <rdar://problem/8986308> (a libc++
SFINAE issue) and the Boost.Polygon failure.
llvm-svn: 127150
declaration because of interesting ordering dependencies while
instantiating a class template or member class thereof. Complain,
rather than asserting (+Asserts) or silently rejecting the code
(-Asserts).
Fixes the crash-on-invalid in PR8965.
llvm-svn: 127129
template name as the result of substitution. The qualifier is handled
separately by the tree transformer, so we would end up in an
inconsistent state.
This is actually the last bit of PR9016, and possibly also fixes
PR8965. It takes Boost.Icl from "epic fail" down to a single failure.
llvm-svn: 127108
template (not a specialization!), use the "injected" function template
arguments, which correspond to the template parameters of the function
template. This is required when substituting into the default template
parameters of template template parameters within a function template.
Fixes PR9016.
llvm-svn: 127092
transform the type that replaces the template type parameter. In the
vast majority of cases, there's nothing to do, because most template
type parameters are replaced with something non-dependent that doesn't
need further transformation. However, when we're dealing with the
default template arguments of template template parameters, we might
end up replacing a template parameter (of the template template
parameter) with a template parameter of the enclosing template.
This addresses part of PR9016, but not within function
templates. That's a separate issue.
llvm-svn: 127091
to cope with non-type templates by providing appropriate
errors. Previously, we would either assert, crash, or silently build a
dependent type when we shouldn't. Fixes PR9226.
llvm-svn: 127037
DependentTemplateSpecializationType during tree transformation, retain
the NestedNameSpecifierLoc as it was used to translate the template
name, rather than reconstructing it from the template name.
Fixes PR9401.
llvm-svn: 127015
Francois Pichet