<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 30, 2022 at 3:23 AM Louis Dionne via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">ldionne requested changes to this revision.<br>
ldionne added a subscriber: jfb.<br>
ldionne added a comment.<br>
This revision now requires changes to proceed.<br>
<br>
I'm still going to request changes because of the `no_unique_address` thing, but this basically LGTM.<br>
<br>
Thanks a lot for the great patch and the great collaboration on this review. I'm extremely happy with the patch and in particular with the fact that we carefully considered the testing coverage during our review of the class itself (e.g. order of operations in assignment, etc.).<br>
<br>
<br>
<br>
================<br>
Comment at: libcxx/include/__expected/expected.h:54-56<br>
+#ifdef _LIBCPP_NO_EXCEPTIONS<br>
+# include <cstdlib> // for std::abort<br>
+#endif<br>
----------------<br>
jwakely wrote:<br>
> ldionne wrote:<br>
> > IMO the simplicity of always having the same set of transitive includes outweighs the additional `<cstdlib>` include, especially since I think most users will end up including that header anyway. I would just include this header unconditionally.<br>
> Another option would be to use `__builtin_abort()` which requires no header.<br>
That's interesting, I never thought of doing that. For this review, I think we should use `std::abort` to be consistent with what we do everywhere else. And then we should review all places in the library where we use `std::abort` (which is all the potentially-exception-throwing functions) and see whether we can/should use `__builtin_abort` instead.<br>
<br>
<br>
================<br>
Comment at: libcxx/include/__expected/expected.h:619-620<br>
+ union {<br>
+ _Tp __val_;<br>
+ _Err __unex_;<br>
+ };<br>
----------------<br>
huixie90 wrote:<br>
> ldionne wrote:<br>
> > Can we use `[[no_unique_address]]` here? Can you investigate how that attribute interacts with unions? Also, does it make sense to put it on the union itself?<br>
> Here is my finding. <br>
> <br>
> For anonymous union (which is the case in the `expected`, I can't find a way to make `[[no_unique_address]]` to have any effect<br>
> <a href="https://godbolt.org/z/zebh4E94d" rel="noreferrer" target="_blank">https://godbolt.org/z/zebh4E94d</a><br>
> <br>
> For a named union, if we apply `[[no_unique_address]]` on the `union` itself plus all the members of the `union`, we can save some space.<br>
> <a href="https://godbolt.org/z/rGoa7c47d" rel="noreferrer" target="_blank">https://godbolt.org/z/rGoa7c47d</a><br>
> <br>
> So I think we don't need to do anything here<br>
I would suggest using a named union instead so that we can apply `[[no_unique_address]]` to the member.<br>
<br>
For unnamed unions, it looks like the compiler is applying the attribute to the `union` type declaration (not the member declaration). Since `[[no_unique_address]]` applies only to member declarations, the attribute ends up being ignored when used on an unnamed union.<br>
<br>
Also, once that's implemented, let's add a libcxx-specific test that this optimization kicks in as intended.<br>
<br>
<br>
================<br>
Comment at: libcxx/include/__expected/expected.h:863<br>
+<br>
+ _LIBCPP_HIDE_FROM_ABI friend constexpr void swap(expected& __x, expected& __y) //<br>
+ noexcept(noexcept(__x.swap(__y))) {<br>
----------------<br>
huixie90 wrote:<br>
> ldionne wrote:<br>
> > Please make sure you have tests that check that this is "equivalent to" the member swap, i.e. that the same constraints apply. This should be SFINAE friendly if the member swap can't be used, basically.<br>
> `noexcept` does not seem to do SFINAE here. I need to constrain it with `requires`<br>
> <a href="https://godbolt.org/z/E15jK4Ter" rel="noreferrer" target="_blank">https://godbolt.org/z/E15jK4Ter</a><br>
I stand corrected. I was *certain* `noexcept` was an immediate context that you could SFINAE on. TIL.<br>
<br>
I think what you have now with `requires requires` is right. It's OK if it fails with clang-15, let's just add the appropriate `XFAIL`s and we'll remove them when we drop support for 15.<br>
<br>
<br>
================<br>
Comment at: libcxx/test/libcxx/utilities/expected/expected.expected/noexcept.extension.compile.pass.cpp:18<br>
+<br>
+// constexpr expected();<br>
+static_assert(std::is_nothrow_default_constructible_v<std::expected<int, int>>);<br>
----------------<br>
<br>
<br>
<br>
================<br>
Comment at: libcxx/test/libcxx/utilities/expected/expected.expected/value_or.mandates.verify.cpp:49<br>
+ //expected-error-re@*:* {{{{(static_assert|static assertion)}} failed {{.*}}argument has to be convertible to value_type}}<br>
+ //expected-error-re@*:* {{{{no matching conversion for static_cast from 'int' to 'NotConvertibleFromInt'}}}}<br>
+ }<br>
----------------<br>
To get rid of these spurious errors, I would look into this:<br>
<br>
```<br>
// ADDITIONAL_COMPILE_FLAGS: -Xclang -verify-ignore-unexpected=error<br>
```<br>
<br>
See for example `libcxx/test/libcxx/atomics/atomics.syn/incompatible_with_stdatomic.verify.cpp`.<br>
<br>
<br>
================<br>
Comment at: libcxx/test/libcxx/utilities/expected/expected.expected/value_or.mandates.verify.cpp:65<br>
+ std::expected<NotConvertibleFromInt, int> f1{std::in_place};<br>
+ std::move(f1).value_or(5);<br>
+ //expected-error-re@*:* {{{{(static_assert|static assertion)}} failed {{.*}}argument has to be convertible to value_type}}<br>
----------------<br>
EricWF wrote:<br>
> How do we know any of these diagnostics are triggered by the code above them? You need to add a check that at least some diagnostic is emitted from this line.<br>
@huixie90 I would suggest moving this to the same line that you're expecting the error (i.e. current line 65) and dropping `*:*, which tells clang that the error can be on any line of any file (`file:line`). Like this:<br>
<br>
```<br>
std::move(f1).value_or(5); // expected-error-re {{{{(static_assert|static assertion)}} failed {{.*}}argument has to be convertible to value_type}}<br>
```<br>
<br>
That will make for a long line, but it does exactly what I think you want.<br>
<br>
<br>
================<br>
Comment at: libcxx/test/std/utilities/expected/expected.expected/assign/assign.copy.pass.cpp:283<br>
+ }<br>
+#endif<br>
+}<br>
----------------<br>
<br>
<br>
<br>
================<br>
Comment at: libcxx/test/std/utilities/expected/expected.expected/assign/emplace.pass.cpp:51<br>
+<br>
+constexpr bool test() {<br>
+ // has_value<br>
----------------<br>
Do we not need exceptions-related tests here to make sure we perform operations in the right order?<br>
<br>
Please go through all the operations of both the void and the non-void specializations. This is a very high bar, but I think it's worth doing it.<br>
<br>
<br>
================<br>
Comment at: libcxx/test/std/utilities/expected/expected.expected/ctor/ctor.u.pass.cpp:115-125<br>
+ // this is a confusing example, but the behaviour<br>
+ // is exactly what is specified in the spec<br>
+ {<br>
+ struct BaseError {};<br>
+ struct DerivedError : BaseError {};<br>
+<br>
+ std::expected<bool, BaseError> e1(false);<br>
----------------<br>
huixie90 wrote:<br>
> @jwakely Hi Jon, thank you very much for commenting on this patch and they are really helpful. While you are here, what do you think about this test case? If I switch `bool` to `int`, <br>
> ```<br>
> std::expected<int, BaseError> e1(5);<br>
> std::expected<int, DerivedError> e2(e1);<br>
> ```<br>
> <br>
> the other ctor overload<br>
> <br>
> ```<br>
> expected(const expected<U, G>&)<br>
> ```<br>
> will be selected and the `int` value `5` will be copied. <br>
> <br>
> But for `bool`, as `T` (`bool`) is constructible from the `expected`, the other overload will be disabled and this overload will be selected<br>
> ```<br>
> expected(U&&);<br>
> ```<br>
> so instead of copying the `bool` (`false`), it uses `operator bool`, which is `true` this case.<br>
> <br>
> Do you think this behaviour is confusing and not very consistent<br>
This seems surprising to me. It seems like this might not have been the design intent. @jfb perhaps you can comment on this?<br>
<br>
Is this worth a LWG issue?<br></blockquote><div><br></div><div>Yes for an LWG issue. At a minimum it's surprising.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
================<br>
Comment at: libcxx/test/std/utilities/expected/expected.unexpected/class_mandates/const.compile.fail.cpp:1<br>
+//===----------------------------------------------------------------------===//<br>
+//<br>
----------------<br>
Please make this into a `verify.cpp`. We're trying to move away from `compile.fail.cpp` tests because it's too easy to write a test that fails for an unrelated reason.<br>
<br>
Applies to all.<br>
<br>
<br>
Repository:<br>
rG LLVM Github Monorepo<br>
<br>
CHANGES SINCE LAST ACTION<br>
<a href="https://reviews.llvm.org/D124516/new/" rel="noreferrer" target="_blank">https://reviews.llvm.org/D124516/new/</a><br>
<br>
<a href="https://reviews.llvm.org/D124516" rel="noreferrer" target="_blank">https://reviews.llvm.org/D124516</a><br>
<br>
</blockquote></div></div>