expressions that look like pseudo-destructors, e.g.,
p->T::~T()
where p has dependent type.
At template instantiate time, we determine whether we actually have a
pseudo-destructor or a member access, and funnel down to the
appropriate routine in Sema.
Fixes PR6380.
llvm-svn: 97092
now cope with the destruction of types named as dependent templates,
e.g.,
y->template Y<T>::~Y()
Nominally, we implement C++0x [basic.lookup.qual]p6. However, we don't
follow the letter of the standard here because that would fail to
parse
template<typename T, typename U>
X0<T, U>::~X0() { }
properly. The problem is captured in core issue 339, which gives some
(but not enough!) guidance. I expect to revisit this code when the
resolution of 339 is clear, and/or we start capturing better source
information for DeclarationNames.
Fixes PR6152.
llvm-svn: 96367
rebuilding a typename type terminating in a template-id (with
dependent template name, naturally) as a TypenameType when, because
its context could be fully resolved, we should have been building it
as a QualifiedNameType. Fixes PR6268.
llvm-svn: 96084
Sema::ActOnUninitializedDecl over to InitializationSequence (with
default initialization), eliminating redundancy. More importantly, we
now check that a const definition in C++ has an initilizer, which was
an #if 0'd code for many, many months. A few other tweaks were needed
to get everything working again:
- Fix all of the places in the testsuite where we defined const
objects without initializers (now that we diagnose this issue)
- Teach instantiation of static data members to find the previous
declaration, so that we build proper redeclaration
chains. Previously, we had the redeclaration chain but built it
too late to be useful, because...
- Teach instantiation of static data member definitions not to try
to check an initializer if a previous declaration already had an
initializer. This makes sure that we don't complain about static
const data members with in-class initializers and out-of-line
definitions.
- Move all of the incomplete-type checking logic out of
Sema::FinalizeDeclaratorGroup; it makes more sense in
ActOnUnitializedDecl.
There may still be a few places where we can improve these
diagnostics. I'll address that as a separate commit.
llvm-svn: 95657
deduction. This requires refactoring the deduction to have access to the Sema
object instead of merely the ASTContext. Still leaves something to be desired
due to poor source location.
Fixes PR6257 and half of PR6259.
llvm-svn: 95528
params. Don't insert addrof operations when matching against a pointer;
array/function conversions should take care of this for us, assuming the
argument type-checked in the first place. Add a fixme where we seem to be
using a less-restrictive reference type than we should.
Fixes PR 6249.
llvm-svn: 95495
type-checking within a template definition. In this case, the
"instantiated" declaration is just the declaration itself, found
within the current instantiation. Fixes PR6239.
llvm-svn: 95442
when instantiating the declaration of a member template:
- Only check if the have a template template argument at a specific position
when we already know that we have template arguments at that level;
otherwise, we're substituting for a level-reduced template template
parameter.
- When trying to find an instantiated declaration for a template
template parameter, look into the instantiated scope. This was a
typo, where we had two checks for TemplateTypeParmDecl, one of
which should have been a TemplateTemplateParmDecl.
With these changes, tramp3d-v4 passes -fsyntax-only.
llvm-svn: 95421
declaration, we can end up with template-id annotation tokens for
types that have not been converted into type annotation tokens. When
this is the case, translate the template-id into a type and parse as
an expression.
llvm-svn: 95404
template parameter, perform array/function decay (if needed), take the
address of the argument (if needed), perform qualification conversions
(if needed), and remove any top-level cv-qualifiers from the resulting
expression. Fixes PR6226.
llvm-svn: 95309
that is in an anonymous namespace, give that function or variable
internal linkage.
This change models an oddity of the C++ standard, where names declared
in an anonymous namespace have external linkage but, because anonymous
namespace are really "uniquely-named" namespaces, the names cannot be
referenced from other translation units. That means that they have
external linkage for semantic analysis, but the only sensible
implementation for code generation is to give them internal
linkage. We now model this notion via the UniqueExternalLinkage
linkage type. There are several changes here:
- Extended NamedDecl::getLinkage() to produce UniqueExternalLinkage
when the declaration is in an anonymous namespace.
- Added Type::getLinkage() to determine the linkage of a type, which
is defined as the minimum linkage of the types (when we're dealing
with a compound type that is not a struct/class/union).
- Extended NamedDecl::getLinkage() to consider the linkage of the
template arguments and template parameters of function template
specializations and class template specializations.
- Taught code generation to rely on NamedDecl::getLinkage() when
determining the linkage of variables and functions, also
considering the linkage of the types of those variables and
functions (C++ only). Map UniqueExternalLinkage to internal
linkage, taking out the explicit checks for
isInAnonymousNamespace().
This fixes much of PR5792, which, as discovered by Anders Carlsson, is
actually the reason behind the pass-manager assertion that causes the
majority of clang-on-clang regression test failures. With this fix,
Clang-built-Clang+LLVM passes 88% of its regression tests (up from
67%). The specific numbers are:
LLVM:
Expected Passes : 4006
Expected Failures : 32
Unsupported Tests : 40
Unexpected Failures: 736
Clang:
Expected Passes : 1903
Expected Failures : 14
Unexpected Failures: 75
Overall:
Expected Passes : 5909
Expected Failures : 46
Unsupported Tests : 40
Unexpected Failures: 811
Still to do:
- Improve testing
- Check whether we should allow the presence of types with
InternalLinkage (in addition to UniqueExternalLinkage) given
variables/functions internal linkage in C++, as mentioned in
PR5792.
- Determine how expensive the getLinkage() calls are in practice;
consider caching the result in NamedDecl.
- Assess the feasibility of Chris's idea in comment #1 of PR5792.
llvm-svn: 95216
(necessarily simultaneous) changes:
- CXXBaseOrMemberInitializer now contains only a single initializer
rather than a set of initialiation arguments + a constructor. The
single initializer covers all aspects of initialization, including
constructor calls as necessary but also cleanup of temporaries
created by the initializer (which we never handled
before!).
- Rework + simplify code generation for CXXBaseOrMemberInitializers,
since we can now just emit the initializer as an initializer.
- Switched base and member initialization over to the new
initialization code (InitializationSequence), so that it
- Improved diagnostics for the new initialization code when
initializing bases and members, to match the diagnostics produced
by the previous (special-purpose) code.
- Simplify the representation of type-checked constructor initializers in
templates; instead of keeping the fully-type-checked AST, which is
rather hard to undo at template instantiation time, throw away the
type-checked AST and store the raw expressions in the AST. This
simplifies instantiation, but loses a little but of information in
the AST.
- When type-checking implicit base or member initializers within a
dependent context, don't add the generated initializers into the
AST, because they'll look like they were explicit.
- Record in CXXConstructExpr when the constructor call is to
initialize a base class, so that CodeGen does not have to infer it
from context. This ensures that we call the right kind of
constructor.
There are also a few "opportunity" fixes here that were needed to not
regress, for example:
- Diagnose default-initialization of a const-qualified class that
does not have a user-declared default constructor. We had this
diagnostic specifically for bases and members, but missed it for
variables. That's fixed now.
- When defining the implicit constructors, destructor, and
copy-assignment operator, set the CurContext to that constructor
when we're defining the body.
llvm-svn: 94952
in a member access expression referring into the current instantiation
need not be resolved at template definition *if* the current
instantiation has any dependent base classes. Fixes PR6081.
llvm-svn: 93877
identifier always names a type. In the case of a dependent
nested-name-specifier, build a TypenameType to describe the dependent
base type. I'd like to move more of this behavior up into the parser,
but this fixes PR6062.
llvm-svn: 93871
which are instantiations of the member functions of local
classes. These implicit instantiations have to occur at the same time
as---and in the same local instantiation scope as---the enclosing
function, since the member functions of the local class can refer to
locals within the enclosing function. This should really, really fix PR5764.
llvm-svn: 93666
distinguish between nested classes (whose member functions cannot be
parsed until the innermost non-nested class is complete) and local
classes (that are defined within a function but are not necessarily
nested). The upshot of this change, which fixes PR5764, is that the
bodies of member functions of local (non-nested) classes need to be
parsed when the local class is complete (and no later), since they may
refer to function-local static variables, typedefs, enums, etc.
llvm-svn: 93653
to merge the local instantiation scope with the outer local
instantiation scope, so that we can instantiate declarations from the
function owning the local class. Fixes an assert while instantiating
Boost.MPL's BOOST_MPL_ASSERT_MSG.
llvm-svn: 93651
function template declared within a class template did not match a
function in another scope. We really need to rework how
friends-in-templates are semantically checked.
llvm-svn: 93642
references a const variable of integral type, the initializer may be
in a different declaration than the one that name-lookup saw. Find the
initializer anyway. Fixes PR6045.
llvm-svn: 93514
Adjust BuildMemberReferenceExpr to perform the inheritance check on implicit
member accesses, which can arise from unqualified lookups and therefore may
reference decls from enclosing class scopes.
Fixes PR 5838.
llvm-svn: 93510
do not look into base classes if there are any dependent base
classes. Instead, note in the lookup result that we couldn't look into
any dependent bases. Use that new result kind to detect when this case
occurs, so that we can fall back to treating the type/value/etc. as a
member of an unknown specialization.
Fixes an issue where we were resolving lookup at template definition
time and then missing an ambiguity at template instantiation time.
llvm-svn: 93497
finds nothing), and the current instantiation has dependent base
classes, treat the qualified lookup as if it referred to an unknown
specialization. Fixes PR6031.
llvm-svn: 93433
that name constructors, the endless joys of out-of-line constructor
definitions, and various other corner cases that the previous hack
never imagined. Fixes PR5688 and tightens up semantic analysis for
constructor names.
Additionally, fixed a problem where we wouldn't properly enter the
declarator scope of a parenthesized declarator. We were entering the
scope, then leaving it when we saw the ")"; now, we re-enter the
declarator scope before parsing the parameter list.
Note that we are forced to perform some tentative parsing within a
class (call it C) to tell the difference between
C(int); // constructor
and
C (f)(int); // member function
which is rather unfortunate. And, although it isn't necessary for
correctness, we use the same tentative-parsing mechanism for
out-of-line constructors to improve diagnostics in icky cases like:
C::C C::f(int); // error: C::C refers to the constructor name, but
// we complain nicely and recover by treating it as
// a type.
llvm-svn: 93322
why the candidate is non-viable. There's a lot we can do to improve this, but
it's a good start. Further improvements should probably be integrated with the
bad-initialization reporting routines.
llvm-svn: 93277
name a template, when they occur in a base-specifier. This is one of
the (few) places where we know for sure that an identifier followed by
a '<' must be a template name, so we can diagnose and recover well:
test/SemaTemplate/dependent-base-classes.cpp:9:16: error: missing
'template'
keyword prior to dependent template name 'T::apply'
struct X1 : T::apply<U> { }; // expected-error{{missing 'template' ...
^
template
test/SemaTemplate/dependent-base-classes.cpp:12:13: error: unknown
template name
'vector'
struct X2 : vector<T> { }; // expected-error{{unknown template name
'vector'}}
^
2 diagnostics generated.
llvm-svn: 93257
initializers. This isn't actually in the C++ grammar (in any version),
but that's clearly an oversight: both GCC and EDG support this syntax,
and it's used within Boost code. I'll file a core issue proposing
precisely the change made here. Fixes PR6008.
llvm-svn: 93243
context, do not attempt typo correction. This harms performance (as
Abramo noted) and can cause some amusing errors, as in this new
testcase.
llvm-svn: 93240
no viable overloads. Use a different message when the class provides
no operator[] overloads at all; use it for operator(), too.
Partially addresses PR 5900.
llvm-svn: 92894
deterministic and work properly with templates. Once a class that
needs a vtable has been defined, we now do one if two things:
- If the class has no key function, we place the class on a list of
classes whose virtual functions will need to be "marked" at the
end of the translation unit. The delay until the end of the
translation unit is needed because we might see template
specializations of these virtual functions.
- If the class has a key function, we do nothing; when the key
function is defined, the class will be placed on the
aforementioned list.
At the end of the translation unit, we "mark" all of the virtual
functions of the classes on the list as used, possibly causing
template instantiation and other classes to be added to the
list. This gets LLVM's lib/Support/CommandLine.cpp compiling again.
llvm-svn: 92821
Douglas Gregor