Details
- Reviewers
mclow.lists EricWF rsmith
Diff Detail
- Repository
- rL LLVM
Event Timeline
include/deque | ||
---|---|---|
288 | This still requires complete type of _ValueType at deque instantiation. |
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; }; |
Turns out it's not actually invasive to support completing the iterator type with an incomplete value type.
Review please?
This version is way simpler than the last one, and does not have ABI issues.
@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?
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. |
I'm pretty sure it only affects template evaluation order, and does not change the mangling of any name.
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();
}
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.