This avoids emitting the VTable of pmr::memory_resource in every TU.
Details
- Reviewers
ldionne Mordante var-const EricWF - Group Reviewers
Restricted Project - Commits
- rG57215eda64d0: [libc++][PMR] Move the pmr::memory_resource destructor into the dylib
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I am surprised that we don't need to change the ABI list, can you look into why that's not needed?
I would assume it was already exported by the dylib because it wasn't marked with HIDE_FROM_ABI, but can you confirm that?
It does, but there are some bugs which doesn't allow us to add them currently. See D135813.
Also, this changes the initialization/atexit behavior of derived memory resource types.
Specifically, because the destructor is no longer defaulted, it's no longer trivial. So the compiler now needs to emit atexit destructors for global memory resources.
I'm not sure this change actually does what we want. I need a minute to test some things.
So I'm not convinced that we actually emit this vtable. At least not outside of the users control.
Can you provide me with example code that would cause the vtable for this type to be omitted inline?
(without providing a derived class with an inline constructor)
Are you sure about that? The class is already non-trivial because it declares virtual functions, and the only difference I can find here is that it doesn't call the destructor of S.