Summary:
No functionality change.
This code should live here long-term because we should be able to use it
to compute correct vftable names.
It turns out that the most natural way to implement the naming algorithm
is to use a caching layer similar to what we already have for virtual
table info in VTableContext. Subsequent changes will take advantage of
this to fix PR17748, where we have a vbtable name collision.
Reviewers: majnemer
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2499
llvm-svn: 198380
Most importantly, this makes our vtable layout match MSVC's. Previously
we would emit a return adjusting thunk whenever the return types
differed, even if the adjustment would have been trivial.
MSVC does emit some trivial return adjusting thunks, but only if there
was already an overridden method that required a return adjustment.
llvm-svn: 198080
Now CodeGenVTables has only one VTableContext object, which is either
Itanium or Microsoft.
Fixes a FIXME with no functionality change intended.
Ideally we could avoid the downcasts by pushing the things that
reference the Itanium vtable context into ItaniumCXXABI.cpp, but we're
not there yet.
llvm-svn: 197845
This was part of the cause for PR17655. We were generating thunks when
we shouldn't have. I suspect that if we tweak the test case for PR17655
to actually require thunks, we can reproduce the same crash.
llvm-svn: 197836
This makes it consistent with -fdump-record-layouts, which was moved to
outs() in r186219. My reasoning for going with stdout is that when one
of these options is present, the layouts are really a program output,
and shouldn't be interleaved with diagnostics, which are on stderr.
Reviewers: timurrrr
Differential Revision: http://llvm-reviews.chandlerc.com/D2127
llvm-svn: 194279
In r183298, I've used llvm::SmallPtrSet<..., 8> instead of llvm::SmallVector<..., 8> for NewVirtualFunctionsTy by mistake.
This only manifested when a class had more than 8 virtual functions, which wasn't covered by unit-tests
llvm-svn: 183310
In addition, I've made the pointer and reference typedef 'void' rather than T*
just so they can't get misused. I would've omitted them entirely but
std::distance likes them to be there even if it doesn't use them.
This rolls back r155808 and r155869.
Review by Doug Gregor incorporating feedback from Chandler Carruth.
llvm-svn: 158104
filter_decl_iterator had a weird mismatch where both op* and op-> returned T*
making it difficult to generalize this filtering behavior into a reusable
library of any kind.
This change errs on the side of value, making op-> return T* and op* return
T&.
(reviewed by Richard Smith)
llvm-svn: 155808
in vtable layout where virtual methods inherited from virtual bases
could be assigned the same vcall adjustment slot if they shared
a name and parameter signature but differed in their
cv-qualification. The code was already trying to handle this
case, but unfortunately used the ordinary type qualifiers
(which are always empty here) instead of the method qualifiers.
This seems like something that the API should discourage, but
I don't know how to carry that principle out in this instance.
Eliminate this function's need for an ASTContext while we're at it.
This bug affects the ABI, and fixing it brings us into accord with
the Itanium ABI (and GCC's implementation of it), but, obviously,
technically breaks full compatibility with previous releases of Clang.
Just letting you know.
llvm-svn: 153168
Aaron Ballman