<memory>: Fix constraints of shared_ptr's constructors when the involved pointer type would be invalid

[frederick-vs-ja]

There are weird things in [util.smartptr.shared.const]/3 and [util.smartptr.shared.const]/9.1: Y(*)[N] or Y(*)[] is not necessary a valid type, e.g. when Y is T[] or a function type, which means that the constraints themselves can be sometimes ill-formed.

Presumably there should be substitution failures in such cases (instead of hard errors or UB/IFNDR). I've tried to submit an LWG issue for this.

void_t<decltype(static_cast<_Yty (*)[]>(nullptr))> works while void_t<_Yty (*)[]> doesn't for MSVC. Reported DevCom-10548086.

Unblocks 2 libcxx tests:

• std/utilities/memory/util.smartptr/util.smartptr.shared/util.smartptr.shared.const/pointer.pass.cpp
• std/utilities/memory/util.smartptr/util.smartptr.shared/util.smartptr.shared.mod/reset_pointer.pass.cpp

[StephanTLavavej]

I pushed a merge with main to resolve a trivial adjacent-delete conflict in tests/libcxx/expected_results.txt.

Thanks for investigating and fixing this failure! 😻 I noticed that the DevCom bug you reported was near-immediately fixed, so I appropriately tagged it internally as fixed in VS 2022 17.10 Preview 1, and added it to my notes for when I perform the 17.10p1 toolset update.

[StephanTLavavej]

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

[StephanTLavavej]

Thanks for fixing these libcxx failures and making our smart pointers even smarter! 🧠 📈 😹