This is an archive of the discontinued LLVM Phabricator instance.

Allow deque to handle incomplete types
ClosedPublic

Authored by eugenis on Jun 23 2015, 5:37 PM.

Details

Diff Detail

Repository
rL LLVM

Event Timeline

rsmith updated this revision to Diff 28311.Jun 23 2015, 5:37 PM
rsmith retitled this revision from to Allow deque to handle incomplete types.
rsmith updated this object.
rsmith edited the test plan for this revision. (Show Details)
eugenis added inline comments.
include/deque
288

This still requires complete type of _ValueType at deque instantiation.

rsmith added inline comments.Jun 23 2015, 6:07 PM
include/deque
288

This requires _ValueType to be complete when deque::iterator is instantiated, not when deque is instantiated. It's easy enough to remove this member, but that patch would be more intrusive, and it's not necessary to support the guarantees that N4510 provides. This patch passes all libc++ test cases with and without _LIBCPP_NEW_DEQUE_ABI defined, and is sufficient to support this:

#include <deque>
struct X {
  std::deque<X> dx;
};
rsmith updated this revision to Diff 28313.Jun 23 2015, 6:12 PM

Turns out it's not actually invasive to support completing the iterator type with an incomplete value type.

eugenis commandeered this revision.Jun 25 2015, 1:23 PM
eugenis updated this revision to Diff 28496.
eugenis added a reviewer: rsmith.

Add a test.

eugenis edited subscribers, added: Unknown Object (MLST); removed: eugenis.

Review please?
This version is way simpler than the last one, and does not have ABI issues.

Any opinions?

EricWF edited edge metadata.Jul 28 2015, 1:02 PM

@eugenis: Sorry for the long delay and multiple pings.

I don't feel comfortable adopting ABI changes until libc++ has a concrete plan for adopting, managing and testing these changes.

@mclow.lists proposed a method for managing these changes a while ago but it hasn't moved forward.
(see http://clang-developers.42468.n3.nabble.com/Proposal-Managing-ABI-changes-in-libc-td4042799.html)

What I want to avoid creating a disjoint set preprocessor macros that change the libc++ ABI. Until we have an idea about how to manage these changes I don't know what to do with this patch.

I am very sorry and thanks for the patch. Hopefully we will figure something out soon.

Thanks for your comment!

That thread you point to seems to end with people agreeing with Chandler's plan. Could you update it please if you have any concerns?

This patch seem to be in line with that plan in general, modulo the preprocessor macro name, and the fact that the high-level version macros remain unimplemented. Would you like that implementation to be done first?

eugenis updated this revision to Diff 37310.Oct 13 2015, 6:30 PM
eugenis edited edge metadata.
eugenis set the repository for this revision to rL LLVM.

Using new ABI version macros to enable this feature in unstable or future ABI only.
PTAL.

For the most part this looks good. I'm a touch concerned though about the changes to the static initialization. The initializer is moved from within the function body to outside it. Could you have somebody confirm this won't affect the existing ABI?

include/__config
34

I think we need a short explanation of ever option added here. In this case could you just link to the bug report and a short explanaition?

ex.

// Fix deques iterator type in order to support incomplete types. See http://llvm.org/bugs/...
#define _LIBCPP_ABI_INCOMPLETE_TYPES_IN_DEQUE
include/deque
270–278

Please leave a note here explaining why the template parameter was kept even though its unused.

test/std/containers/sequences/deque/deque.cons/incomplete.pass.cpp
9 ↗(On Diff #37310)

This test needs to go into test/libcxx not test/std because it's testing libc++ implementation details and not standard specified behavior.

eugenis updated this revision to Diff 37795.Oct 19 2015, 2:27 PM
eugenis marked 3 inline comments as done.

For the most part this looks good. I'm a touch concerned though about the changes to the static initialization. The initializer is moved from within the function body to outside it. Could you have somebody confirm this won't affect the existing ABI?

I'm pretty sure it only affects template evaluation order, and does not change the mangling of any name.

EricWF added a subscriber: EricWF.Oct 21 2015, 5:51 PM

I'm pretty sure it only affects template evaluation order, and does not

change the mangling of any name.

I agree it doesn't change the mangling of any name. I just want to make
sure that moving the initializer won't result in incompatible code gen.
I'm sure I'm insane for being concerned about this, but I just want
somebody to tell me I'm actually insane. It would make me feel better :)

Sorry
/Eric

What kind of confirmation are you looking for?

I've compiled the following code with 2 versions of <deque>: one as in this review, another the same but with __block_size initializers moved back into respective classes. Resulting object files are identical.

#include <deque>

int main() {

std::deque<int> d;
d.push_back(1);
d.push_back(2);
for (auto x : d) (void)x;
return d.size();

}

Hi Eric,

could you please clarify what exactly you are looking for here?

EricWF accepted this revision.Nov 6 2015, 1:47 PM
EricWF edited edge metadata.

I think I've cleared up my own confusion. LGTM.

This revision is now accepted and ready to land.Nov 6 2015, 1:47 PM
eugenis closed this revision.Nov 6 2015, 2:05 PM

Thanks!
Landed as r252350.