Douglas Gregor [Thu, 25 Mar 2010 00:20:38 +0000 (00:20 +0000)]
Kill off two more uses of Sema::CheckReferenceInit in favor of the new
initialization code. Exposed a bug where we were not marking an
implicit conversion as an lvalue when we were forming a call to a
conversion function whose return type is a reference.
Douglas Gregor [Wed, 24 Mar 2010 23:38:29 +0000 (23:38 +0000)]
Switch static_cast from the old reference-initialization code (via
CheckReferenceInit) over to the new initialization code
(InitializationSequence), which is better-tested and doesn't require
us to compute the entire conversion sequence twice.
Douglas Gregor [Wed, 24 Mar 2010 23:14:04 +0000 (23:14 +0000)]
When returning from a function that has a reference return type, use
EmitReferenceBindingToExpr() rather than assuming we have an
lvalue. This is just the lowest hanging fruit for PR6024, which still
requires a bit of work.
Rafael Espindola [Wed, 24 Mar 2010 22:43:31 +0000 (22:43 +0000)]
Discussing with dgregor we decided that we should not force the emission of
implicit methods on explicit template instantiation definitions. As a
consequence, we should emit them at every use, even if we see a explicit
template instantiation declaration.
This is already the current behaviour, but it is good to test for that :-)
Douglas Gregor [Wed, 24 Mar 2010 21:22:47 +0000 (21:22 +0000)]
When pulling apart an initializer that involves a CXXConstructExpr, do
not pick apart a CXXTemporaryObjectExpr because such an object
construction was explicitly written in the source code. Fixes PR6657.
Douglas Gregor [Wed, 24 Mar 2010 17:31:23 +0000 (17:31 +0000)]
Silently drop dependent friend function template specializations,
since we have absolutely no way to match them when they are declared
nor do we have a way to represent these parsed-but-not-checked friend
declarations.
John McCall [Wed, 24 Mar 2010 08:27:58 +0000 (08:27 +0000)]
Correct that last fixit: if the user wrote
template <> friend void foo(int);
we need to change it to
friend void foo<>(int);
or else the user won't get the template specialization they obviously want.
Douglas Gregor [Wed, 24 Mar 2010 07:14:45 +0000 (07:14 +0000)]
When a declaration of a function is missing an exception specification
that was present in a prior declaration, emit a warning rather than a
hard error (which we did before, and still do with mismatched
exception specifications). Moreover, provide a fix-it hint with the
throw() clause that should be added, e.g.,
t.C:10:7: warning: 'operator new' is missing exception specification
'throw(std::bad_alloc)'
void *operator new(unsigned long sz)
^
throw(std::bad_alloc)
As part of this, disable the warning when we're missing an exception
specification on operator new, operator new[], operator delete, or
operator delete[] when exceptions are turned off (-fno-exceptions).
John McCall [Wed, 24 Mar 2010 05:22:00 +0000 (05:22 +0000)]
Implement a framework for the delay of arbitrary diagnostics within
templates. So delay access-control diagnostics when (for example) the target
of a friend declaration is a specific specialization of a template.
I was surprised to find that this was required for an access-controlled selfhost.
Douglas Gregor [Wed, 24 Mar 2010 05:07:21 +0000 (05:07 +0000)]
When performing name lookup for the allocation or deallocation
operators, make sure that the implicitly-declared global new and
delete operators are always available. Fixes PR5904.
Douglas Gregor [Wed, 24 Mar 2010 00:46:35 +0000 (00:46 +0000)]
Make sure to properly track the anonymous namespace that lives inside
each namespace, even when the outer namespace has multiple
definitions. As part of this, collapsed two pointers worth of storage
(original namespace and inner anonymous namespace) into a single
pointer with a distinguishing bit, since the two are mutually
exclusive, saving a pointer per NamespaceDecl. Fixes PR6620.
Douglas Gregor [Tue, 23 Mar 2010 23:47:56 +0000 (23:47 +0000)]
Implement computation of the final overriders for each virtual
function within a class hierarchy (C++ [class.virtual]p2).
We use the final-overrider computation to determine when a particular
class is ill-formed because it has multiple final overriders for a
given virtual function (e.g., because two virtual functions override
the same virtual function in the same virtual base class). Fixes
PR5973.
We also use the final-overrider computation to determine which virtual
member functions are pure when determining whether a class is
abstract or diagnosing the improper use of an abstract class. The
prior approach to determining whether there were any pure virtual
functions in a class didn't cope with virtual base class subobjects
properly, and could not easily be fixed to deal with the oddities of
subobject hiding. Fixes PR6631.
Douglas Gregor [Tue, 23 Mar 2010 15:26:55 +0000 (15:26 +0000)]
When recovering from a qualified typedef name, don't clear out the
DeclContext because we don't want a NULL DeclContext. Instead, use the
current context.
Daniel Dunbar [Tue, 23 Mar 2010 05:09:16 +0000 (05:09 +0000)]
Frontend: Don't free the CompilerInstance or FrontendActions when running under
-disable-free. Among other things, this fixes freeing of the LLVM module on
exit.
- Note that this means we are disable-free'ing of a lot more stuff than we used to -- this should flush out bugs in anything left that is trying to do real work in its destructor. I did a mini-audit but '::~' is not totally uncommon.
Zhongxing Xu [Tue, 23 Mar 2010 05:05:02 +0000 (05:05 +0000)]
Since we now may have basicblocks with the same block is in different function,
change the block counter map from unsigned -> unsigned to
<StackFrameContext*, unsigned> -> unsigned.
Rafael Espindola [Mon, 22 Mar 2010 23:12:48 +0000 (23:12 +0000)]
A fixed version of r99174 which also includes a test that we emit vtables when
we see an specialization definition ever if we then see a extern template declaration.
More clean up of ivars which are either in class extensions and
implementation or synthesized into an implementation. Also,
fixes a code gen. bug when ivars are itroduced in interleaved
implementations. (related to radar 7547942).
Douglas Gregor [Mon, 22 Mar 2010 15:53:50 +0000 (15:53 +0000)]
Use the cursor's ASTContext rather than the ASTContext computed from a
declaration, just in case invalid code makes the latter
incorrect. This may be the cause behind <rdar://problem/7777070>.
Douglas Gregor [Mon, 22 Mar 2010 15:10:57 +0000 (15:10 +0000)]
Introduce the notion of a single "delayed" diagnostic into the
Diagnostic subsystem, which is used in the rare case where we find a
serious problem (i.e., an inconsistency in the file system) while
we're busy formatting another diagnostic. In this case, the delayed
diagnostic will be emitted after we're done with the other
diagnostic. This is only to be used for fatal conditions detected at
very inconvenient times, where we can neither stop the current
diagnostic in flight nor can we suppress the second error.
projects / clang / log