| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 198085
|
|
|
|
| |
llvm-svn: 198081
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Reviewed at http://llvm-reviews.chandlerc.com/D2120
llvm-svn: 194256
|
|
|
|
|
|
| |
field with a more appropriate name
llvm-svn: 194202
|
|
|
|
| |
llvm-svn: 194132
|
|
|
|
| |
llvm-svn: 194082
|
|
|
|
|
|
|
|
| |
adjustment when using -cxx-abi microsoft
Reviewed at http://llvm-reviews.chandlerc.com/D2026
llvm-svn: 193679
|
|
|
|
|
|
| |
reduce code duplication
llvm-svn: 193610
|
|
|
|
| |
llvm-svn: 193164
|
|
|
|
|
|
|
|
| |
destructors in the presence of virtual bases
Reviewed at http://llvm-reviews.chandlerc.com/D1939
llvm-svn: 192822
|
|
|
|
|
|
| |
No functionality change.
llvm-svn: 192598
|
|
|
|
|
|
| |
ItaniumVTableBuilder and clang-format code around
llvm-svn: 192288
|
|
|
|
|
|
| |
simple thunks when using -cxx-abi microsoft" with relaxed assertions
llvm-svn: 192285
|
|
|
|
| |
llvm-svn: 192225
|
|
|
|
|
|
|
|
| |
when using -cxx-abi microsoft
Reviewed at http://llvm-reviews.chandlerc.com/D1787
llvm-svn: 192220
|
|
|
|
| |
llvm-svn: 192067
|
|
|
|
|
|
|
|
| |
when using -cxx-abi microsoft
Reviewed at http://llvm-reviews.chandlerc.com/D1532
llvm-svn: 191523
|
|
|
|
|
|
| |
implement them for -cxx-abi microsoft
llvm-svn: 188870
|
|
|
|
| |
llvm-svn: 187574
|
|
|
|
| |
llvm-svn: 187409
|
|
|
|
| |
llvm-svn: 185715
|
|
|
|
| |
llvm-svn: 185438
|
|
|
|
| |
llvm-svn: 185159
|
|
|
|
| |
llvm-svn: 185101
|
|
|
|
|
|
|
|
|
| |
VTableContext::ComputeMethodVTableIndices() and VTableContext::getNumVirtualFunctionPointers()'
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 libcxx __locale
llvm-svn: 183305
|
|
|
|
|
|
| |
-Werror build to fail
llvm-svn: 183300
|
|
|
|
| |
llvm-svn: 183299
|
|
|
|
|
|
| |
VTableContext::getNumVirtualFunctionPointers(); also add some tests for the VTable indices output to make sure we don't regress
llvm-svn: 183298
|
|
|
|
| |
llvm-svn: 181396
|
|
|
|
| |
llvm-svn: 175045
|
|
|
|
| |
llvm-svn: 174292
|
|
|
|
| |
llvm-svn: 173514
|
|
|
|
| |
llvm-svn: 173035
|
|
|
|
| |
llvm-svn: 169095
|
|
|
|
| |
llvm-svn: 166056
|
|
|
|
| |
llvm-svn: 160622
|
|
|
|
|
|
|
|
| |
instead.
No functionality change.
llvm-svn: 159719
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
value_type
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
|
|
|
|
| |
llvm-svn: 154748
|
|
|
|
| |
llvm-svn: 154747
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
|
|
|
| |
llvm-svn: 152475
|