Douglas Gregor [Thu, 13 May 2010 21:36:56 +0000 (21:36 +0000)]
Disable the available_externally optimization for inline virtual
methods for which the key function is guaranteed to be in another
translation unit. Unfortunately, this guarantee isn't the case when
dealing with shared libraries that fail to export these virtual method
definitions.
I'm reopening PR6747 so we can consider this again at a later point in
time.
Douglas Gregor [Thu, 13 May 2010 16:44:06 +0000 (16:44 +0000)]
Rework when and how vtables are emitted, by tracking where vtables are
"used" (e.g., we will refer to the vtable in the generated code) and
when they are defined (i.e., because we've seen the key function
definition). Previously, we were effectively tracking "potential
definitions" rather than uses, so we were a bit too eager about emitting
vtables for classes without key functions.
The new scheme:
- For every use of a vtable, Sema calls MarkVTableUsed() to indicate
the use. For example, this occurs when calling a virtual member
function of the class, defining a constructor of that class type,
dynamic_cast'ing from that type to a derived class, casting
to/through a virtual base class, etc.
- For every definition of a vtable, Sema calls MarkVTableUsed() to
indicate the definition. This happens at the end of the translation
unit for classes whose key function has been defined (so we can
delay computation of the key function; see PR6564), and will also
occur with explicit template instantiation definitions.
- For every vtable defined/used, we mark all of the virtual member
functions of that vtable as defined/used, unless we know that the key
function is in another translation unit. This instantiates virtual
member functions when needed.
- At the end of the translation unit, Sema tells CodeGen (via the
ASTConsumer) which vtables must be defined (CodeGen will define
them) and which may be used (for which CodeGen will define the
vtables lazily).
From a language perspective, both the old and the new schemes are
permissible: we're allowed to instantiate virtual member functions
whenever we want per the standard. However, all other C++ compilers
were more lazy than we were, and our eagerness was both a performance
issue (we instantiated too much) and a portability problem (we broke
Boost test cases, which now pass).
Notes:
(1) There's a ton of churn in the tests, because the order in which
vtables get emitted to IR has changed. I've tried to isolate some of
the larger tests from these issues.
(2) Some diagnostics related to
implicitly-instantiated/implicitly-defined virtual member functions
have moved to the point of first use/definition. It's better this
way.
(3) I could use a review of the places where we MarkVTableUsed, to
see if I missed any place where the language effectively requires a
vtable.
Chandler Carruth [Thu, 13 May 2010 11:37:24 +0000 (11:37 +0000)]
Teach the AKA calculation to look at sugar on the pointee type for pointers and
references. This is a WIP as we should handle function pointers, etc. Reshuffle
the code to do this to facilitate recursing in this manner, and to check for
the type already being printed first rather than last.
Chandler Carruth [Thu, 13 May 2010 07:43:05 +0000 (07:43 +0000)]
Update the types for warning option subgroup arrays to 'short', we have more
than 127 groups so this was already failing given -fsigned-char. A subsequent
to commit to TableGen will generate shorts for the arrays themselves.
Devang Patel [Wed, 12 May 2010 23:46:38 +0000 (23:46 +0000)]
If given location is invalid then use current location.
This fixes recent regressions reported by gdb testsuite.
Tighter verification of debug info generated by FE found these regressions.
Refactor code to extract line number and column number from SourceLocation.
Douglas Gregor [Wed, 12 May 2010 17:27:19 +0000 (17:27 +0000)]
Whenever we instantiate a function definition or class, enter a new
potentially-evaluated expression context, to ensure that used
declarations get properly marked. Fixes PR7123.
Douglas Gregor [Wed, 12 May 2010 16:39:35 +0000 (16:39 +0000)]
When we emit an error during the implicit definition of a special
member function (default constructor, copy constructor, copy
assignment operator, destructor), emit a note showing where that
implicit definition was required.
Ted Kremenek [Wed, 12 May 2010 06:00:25 +0000 (06:00 +0000)]
Correctly check if a cursor is a declaration before returning its location/range in clang_getCursorLocation()/clang_getCursorExtent(). This fixes a horrible bug reported in
<rdar://problem/7961995> and <rdar://problem/7967123> where declarations with attributes
would get grossly annotated with the wrong tokens because the attribute would be interpreted
as if it was a Decl*.
John McCall [Wed, 12 May 2010 00:58:13 +0000 (00:58 +0000)]
When checking scopes for indirect goto, be more permissive (but still safe)
about the permitted scopes. Specifically:
1) Permit labels and gotos to appear after a prologue of variable initializations.
2) Permit indirect gotos to jump out of scopes that don't require cleanup.
3) Diagnose possible attempts to indirect-jump out of scopes that do require
cleanup.
This requires a substantial reinvention of the algorithm for checking indirect
goto. The current algorithm is Omega(M*N), with M = the number of unique
scopes being jumped from and N = the number of unique scopes being jumped to,
with an additional factor that is probably (worst-case) linear in the depth
of scopes. Thus the entire thing is likely cubic given some truly bizarre
ill-formed code; on well-formed code the additional factor collapses to
an amortized constant (when amortized over the entire function) and so
the algorithm is quadratic. Even this requires every label to appear in
its own scope, which would be very unusual for indirect-goto code (and
extremely unlikely for well-formed code); it is far more likely that
all labels will be in the same scope and so the algorithm becomes linear.
For such a marginal feature, I am fairly happy with this result.
(this is using JumpDiagnostic's definition of scope, where successive
variables in a block appear in their own scope)
Douglas Gregor [Tue, 11 May 2010 20:24:17 +0000 (20:24 +0000)]
Do not mark the virtual members of an implicitly-instantiated class as
referenced unless we see one of them defined (or the key function
defined, if it as one) or if we need the vtable for something. Fixes
PR7114.
Douglas Gregor [Tue, 11 May 2010 17:39:34 +0000 (17:39 +0000)]
The C++98/03 standard is disturbingly silent about out-of-scope
explicit instantiations of template. C++0x clarifies the intent
(they're ill-formed in some cases; see [temp.explicit] for
details). However, one could squint at the C++98/03 standard and
conclude they are permitted, so reduce the error to a warning
(controlled by -Wc++0x-compat) in C++98/03 mode.
Douglas Gregor [Tue, 11 May 2010 16:41:27 +0000 (16:41 +0000)]
Static data members intialized in-class that have constant values are
value-dependent if their initializers are value-dependent; my recent
tweak to these dependent rules overstepped by taking away this
value-dependents. Fixes a Boost.GIL regression.
Douglas Gregor [Tue, 11 May 2010 08:41:30 +0000 (08:41 +0000)]
A DeclRefExpr that refers to a member function or a static data member
of the current instantiation is value-dependent. The C++ standard
fails to enumerate this case and, therefore, we missed it. Chandler
did all of the hard work of reducing the last remaining
Boost.PtrContainer failure (which had to do with static initialization
in the Serialization library) down to this simple little test.
While I'm at it, clean up the dependence rules for template arguments
that are declarations, and implement the dependence rules for template
argument packs.
Chandler Carruth [Tue, 11 May 2010 08:02:08 +0000 (08:02 +0000)]
Add a test for a subtle instantiation pattern that showed up within a Boost
miscompile reduction. Clang already handles this correctly, but let's make sure
it stays that way.
John McCall [Mon, 10 May 2010 23:27:23 +0000 (23:27 +0000)]
Refactor the constant-evaluator so that it only supports a single form
of constant-evaluation. Formerly you could control whether it accepted
local l-values or not; now it always evaluates local l-values in the core
routines, but filters them out where consumed by the top-level routines.
This will make it much easier to cache evaluability.
Ted Kremenek [Mon, 10 May 2010 20:40:08 +0000 (20:40 +0000)]
Start converting pieces of DeclarationNameTable to be allocated using ASTContext's allocator.
While DeclarationNameTable doesn't leak, it uses 'malloc' too often. Start with having
'CXXLiteralOperatorNames' allocated using ASTContext's allocator and add a 'DoDestroy()' method
to DeclarationNameTable that is called by ~ASTContext.
Chris Lattner [Sun, 9 May 2010 05:36:05 +0000 (05:36 +0000)]
pchify CXXMemberCallExpr correctly. Before it would serialize
and deserialize as a CallExpr which is close, but ends up
deserializing with the wrong stmt class.
Douglas Gregor [Sat, 8 May 2010 23:34:38 +0000 (23:34 +0000)]
Fix a silly bootstrap-breaking thinko, where we were trying to convert
non-existent condition expressions to boolean values during template
instantiation.
Douglas Gregor [Sat, 8 May 2010 23:05:03 +0000 (23:05 +0000)]
Improve our handling of the -Wunused-variable warning in templates. In
particular, don't complain about unused variables that have dependent
type until instantiation time, so that we can look at the type of the
variable. Moreover, only complain about unused variables that have
neither a user-declared constructor nor a non-trivial destructor.
Anders Carlsson [Sat, 8 May 2010 22:35:05 +0000 (22:35 +0000)]
Add a SizeOfLargestEmptySubobject member to ASTRecordLayout. For C++ classes this will hold the largest empty subobject or 0 if the class doesn't have any empty subobjects.
Douglas Gregor [Sat, 8 May 2010 22:20:28 +0000 (22:20 +0000)]
When instantiating statements that involve conditions (if, while, do,
for, and switch), be careful to construct the full expressions as soon
as we perform template instantation, so we don't either forget to call
temporary destructors or destroy temporaries at the wrong time. This
is the template-instantiation analogue to r103187, during which I
hadn't realized that the issue would affect the handling of these
constructs differently inside and outside of templates.
Douglas Gregor [Sat, 8 May 2010 19:15:54 +0000 (19:15 +0000)]
Improve overload-candidate diagnostic for a function template that
failed because the explicitly-specified template arguments did not
match its template parameters, e.g.,
Douglas Gregor [Sat, 8 May 2010 18:13:28 +0000 (18:13 +0000)]
When template argument deduction fails because the call had too
many/too few arguments, use the same diagnostic we use for arity
mismatches in non-templates (but note that it's a function template).
projects / clang / log