[libcxx-commits] [PATCH] D116346: [libc++] Fix __wrap_iter copy-assignment in constexpr contexts

[Arthur O'Dwyer via Phabricator via libcxx-commits]

Quuxplusone added inline comments.


================
Comment at: libcxx/test/std/strings/basic.string/string.iterators/iterators.pass.cpp:58
+        i2 = i1;
+        assert ( i1 == i2 );
+    }
----------------
philnik wrote:
> Quuxplusone wrote:
> > Before line 57, let's `assert ( i1 != i2 );`
> > Notice that this test won't work until std::string becomes constexpr, which is why it's `#if`'ed out on line 82 below.
> > ...Waitaminute. Since we're still waiting for CI to come back, anyway, could you please investigate why this godbolt (using `span` instead of `string` to get its `__wrap_iter`s) does //not// reproduce the bug? I think it //should// fail, but I must be missing something.
> > https://godbolt.org/z/4aGTK79b5
> > 
> You forgot to add `-D_LIBCPP_DEBUG=1` to your command line args.
`-D_LIBCPP_DEBUG=1` would make https://godbolt.org/z/4aGTK79b5 fail to compile because `std::span<int>::iterator` would be just `int*`, not `__wrap_iter<int*>`. ...Ah, I get it. Right now `__wrap_iter<T>::operator=` is broken only at constexpr time and //only when `_LIBCPP_DEBUG_LEVEL == 2`//.
At that debug level, `span<int>::iterator` is not `__wrap_iter`, so we can't use `span` to reproduce the bug either.
Okay, I'm convinced that it's impossible to trigger this bug right now, and so the `#if`'ed-out test you have here is the best we can do, and so IMO once buildkite is back and green, this is good to go.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D116346/new/

https://reviews.llvm.org/D116346