<expected>: Make copy/move assignment operators of expected propagate triviality

[frederick-vs-ja]

The conditions for triviality should be consistent with optional and variant (see WG21-P0602R4). I've tried to submit an LWG issue for this, but I believe we can conformingly do this without changing the standard wording. Edit: the issue is now LWG-4026.

The changes are also being made in libc++, see LLVM-74768.

Old test coverage was a bit crazy

More than 1000 function template specializations are instantiated. But I have no good idea to reduce the instantiation.

• It was actually somehow bad, there're failures with "fatal error C1060: compiler is out of heap space".

Edit: reduced the cases from 32×32 to 6×6.

[StephanTLavavej]

As I mentioned on Discord, the #ifdef EXHAUSTIVE technique seen in a few other tests would be applicable. I don't think we need the full 2^N combinatoric explosion for normal automated testing. Instead, it should be sufficient to test that each individual condition can influence the outcome (e.g. a type where only the copy assignment is non-trivial).

Also, /d1reportMemorySummary can be used to check the compiler's peak working set size. We don't have a specific limit for this, but in my opinion any test that consumes more than 1 GB for either x86 or x64 is doing too much work. We have a number of ranges tests that exceed this and they're quite problematic.

[CaseyCarter]

As I mentioned on Discord, the #ifdef EXHAUSTIVE technique seen in a few other tests would be applicable. I don't think we need the full 2N combinatoric explosion for normal automated testing. Instead, it should be sufficient to test that each individual condition can influence the outcome (e.g. a type where only the copy assignment is non-trivial).

In practice, there are (1) no types for which copy operations are trivial but moves are not, (2) no types for which assignment is trivial but construction is not, and (3) no types for which some copy or move operation is trivial but destruction is not. It's sufficient to test five cases:

1. no trivial operations
2. only destruction is trivial
3. only destruction and move construct are trivial
4. only destruction and move construct/assign are trivial
5. only destruction and move/copy construct are trivial
6. destruction and move/copy construct/assign are all trivial.
   Other cases only exist in test suites and it's a waste of time to specify (let alone test) their behavior.

[StephanTLavavej]

I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed.

[StephanTLavavej]

Thanks for this highly nontrivial enhancement! 😹 🎉 🚀