fix typo

[fsb4000]

The link was correct. There is no https://wg21.link/p0962r2

By the way cppreference has https://wg21.link/P0593R6 but your table doesn't have the row. I'm not sure if this row is needed in your table, but I would be very grateful if you could say when P0593R6 was implemented for MSVC?

[PRMerger15]

@fsb4000 : Thanks for your contribution! The author(s) have been notified to review your proposed change.

[colin-home]

Looks good, thanks. I'll look into the other issue.

[colin-home]

@fsb4000
The compiler dev team were of the opinion that p0593r6 was a no-op for compiler behavior, and closed the related work item a year ago without adding it to the tracking table I use to populate the conformance page. I can add it, but the version column would say N/A.

[fsb4000]

@corob-msft

Thank you very much! I added "N/A" to the cppreference table.

[colin-home]

@fsb4000
I wonder if "Yes" is better than "N/A" for P0593R6, since all versions of the MSVC compiler show the required behavior. The only difference is, that behavior is no longer considered undefined. Lifetime analysis is optionally run in a separate tool (even though it's invoked by the /analyze compiler switch), so there have never been compiler diagnostics that would need to be turned off to support P0593R6.

I see a similar N/A marking for P1236R1; This entry probably also deserves a "Yes". Signed integers have always been two's complement in the Microsoft compilers. It's the native representation on all architectures MSVC has ever supported. There's never been MSVC support for one's complement or sign-magnitude arithmetic.

[fsb4000]

Done! Thanks again!

[frederick-vs-ja]

@corob-msft
P0593R6 changes the semantics of pseudo-destructor call, making it end the lifetime of a scalar object. And as pseudo-destructor call and explicit destructor call (given the destructor is constexpr) are allowed in constant evaluation via P0784R7, UB introduced by P0593R6 (out-of-lifetime access) are required to be diagnosed in constant evaluation.
So P0593R6 is not no-op for compiler behavior IMO.

"Yes" is better for P1236R1, as left shift operations changed from undefined to well-defined is not diagnosed in constant expression (e.g. constexpr int i = (-1) << 15; is accepted, even in VS2015). However, in order to be conformant to C++14/17, such operations should be diagnosed in C++14/17 modes.