Allow promises to be constructed for non-default-constructible types

[MitalAshok]

A fix for #2488 without breaking ABI compatibility.

For types that are not default constructible, promise<T> will now act like it was supposed to all along (set_value will copy/move construct a value rather than copy/move assign it). The value is stored like a std::optional, where _Has_stored_result is repurposed to be "has a value been constructed", and its old purpose is replaced with _Has_stored_result || (_Exception != nullptr).

Differences are guarded with is_default_constructible<_Ty> to have the same behaviour as before, except that promise<T>::set_exception(nullptr) has been explicitly disallowed (It was already UB, since a precondition of set_exception_ptr/set_exception_at_thread_exit is "p is not null.", and would make get return a default constructed value).

I also removed a member function void _Set_value(bool _At_thread_exit); that had the comment // store a (void) result and its corresponding _Set_value_raw function, since they were unused and it would be a logical error to call them with a non-default-constructible type.

In vNext, promise<T> can be fixed for all types by replacing all the is_default_constructible<_Ty> checks with false.

[ghost]

All CLA requirements met.

[StephanTLavavej]

Thanks for fixing this long-standing bug! (I can't count how many times it's been reported over the years, but it's definitely "lots".) Main feedback here is a request for test coverage, plus minor codebase convention nitpicks. Your strategy looks good to me and it should preserve binary compatibility.

[MitalAshok]

I've also (re)discovered this bug:

STL/stl/inc/future

Lines 265 to 275 in afe0800

	virtual _Ty& _Get_value(bool _Get_only_once) {
	unique_lock<mutex> _Lock(_Mtx);
	if (_Get_only_once && _Retrieved) {
	_Throw_future_error(make_error_code(future_errc::future_already_retrieved));
	}
	if (_Exception) {
	_Rethrow_future_exception(_Exception);
	}
	_Retrieved = true;

Also seen here: https://stackoverflow.com/a/42648634

Since _Retrieved is not set before the exception is thrown, the shared state isn't invalidated when future::get throws an exception, and the post condition [futures.unique.future]p17 "Postconditions: valid() == false" isn't held.

The fix would be a breaking change. I could have it fixed only with the new behaviour, or have the new behaviour follow the old behaviour in this edge case and just add a comment that it needs to be fixed.

[StephanTLavavej]

Test looks good, thank you! One more set of small comments (the most significant being the Standard citation, which isn't very significant) and I think this will be ready to go 🚀

[StephanTLavavej]

I've pushed a merge with main (no conflicts) followed by Casey's requested changes (I added backticks for consistency to one comment, no other changes). Should be ready to merge after @CaseyCarter's swift approval.

[StephanTLavavej]

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

[StephanTLavavej]

Thanks again for fixing this long-standing bug, and congratulations on your first microsoft/STL commit! 🎉 🚀 😻

This will ship in VS 2022 17.2 Preview 3.