Deprecation of non-floating complex

[AlexGuteniev]

Deprecation of nonstandard extension mentioned in #756

[AlexGuteniev]

So here are unexpected failures:

: Failing Tests (12):
1:   libc++ :: std/numerics/complex.number/cmplx.over/real.pass.cpp:0
1:   libc++ :: std/numerics/complex.number/cmplx.over/imag.pass.cpp:0
1:   libc++ :: std/numerics/complex.number/cmplx.over/real.pass.cpp:1
1:   libc++ :: std/numerics/complex.number/complex.member.ops/times_equal_complex.pass.cpp:0
1:   libc++ :: std/numerics/complex.number/complex.member.ops/times_equal_complex.pass.cpp:1
1:   libc++ :: std/numerics/complex.number/complex.member.ops/minus_equal_complex.pass.cpp:0
1:   libc++ :: std/numerics/complex.number/cmplx.over/imag.pass.cpp:1
1:   libc++ :: std/numerics/complex.number/complex.member.ops/plus_equal_complex.pass.cpp:0
1:   libc++ :: std/numerics/complex.number/complex.member.ops/plus_equal_complex.pass.cpp:1
1:   libc++ :: std/numerics/complex.number/complex.members/real_imag.pass.cpp:0
1:   libc++ :: std/numerics/complex.number/complex.members/real_imag.pass.cpp:1
1:   libc++ :: std/numerics/complex.number/complex.member.ops/minus_equal_complex.pass.cpp:1

I'm trying to fix them by passing /D_SILENCE_NONFLOATING_COMPLEX_DEPRECATION_WARNING to cl when running libcxx tests.

[AlexGuteniev]

Now test pass. Interestingly. complex<int> extension is only covered by libcxx test.

[CaseyCarter]

It's not clear to me that we want to deprecate this functionality. Do you have any motivating arguments?

[CaseyCarter]

We typically add deprecation suppression defines to msvc_stdlib_force_include.h to keep the command line from growing without bound. (I wouldn't put any effort into upstreaming that change until we decide if we want this deprecation.)

[CaseyCarter]

We can push this change into LLVM after we otherwise finish review of the PR. I'd hate for someone to make the change and then have to do so again if we decide to change the name of the suppression macro.

[CaseyCarter]

Upon further consideration, I don't want to block this waiting for the ranges::is_permutation PR (which includes the pertinent LLVM changes) to merge. I'd be happy to merge this as-is with an issue to move this macro definition from the command line into the header once we're able to update LLVM again.

[AlexGuteniev]

It is not possible to implement many operations for complex<int> properly.
@statementreply observed that sqrt(complex<int>{1, 0}) crashes, for instance.

[StephanTLavavej]

The Standard says that the effects are unspecified, so code using complex<int> isn't portable. I think deprecation is justified because (1) stuff doesn't work as a user might expect (thanks @statementreply and @AlexGuteniev for the example) and (2) this is an ongoing implementation/test cost. For similar reasons, we deprecated and removed <allocators> (although the concerns were more intense there).

Mostly I'm not sure how much usage has accumulated in the last 20+ years, but this is just deprecation with an escape hatch, not removal.

[CaseyCarter]

We discussed this during our weekly meeting and decided we saw no reason not to deprecate, but wanted wait for @StephanTLavavej to return from vacation and possibly provide historical context. The above comment - which was posted shortly before that meeting, but I only noticed just now - is what we were wanting.

I've removed the "decision needed" label so this PR can move forward.

[StephanTLavavej]

Looks good; I'll push a change to qualify std::complex in the deprecation message.

[StephanTLavavej]

Unfortunately, this deprecation warning is causing our "Real World Code" test suite to fail, so I wasn't able to merge this. Either NVIDIA/cutlass#104 needs to be fixed upstream, or we need to figure out how to properly silence this warning in our Microsoft-internal infrastructure (I tried adding a compiler option to define the appropriate macro in our build script via CMake, but it didn't work as I expected, and I ran out of time to continue investigating). 😿

[StephanTLavavej]

NVIDIA/cutlass#104 is still active upstream. I may be able to figure out how to patch their sources in our RWC suite, which should be more effective than attempting to add the compiler option (I've successfully patched code before), but I won't have time to investigate that in the near future.

[AlexGuteniev]

Do you want me to close this PR, convert it to draft, or keep open?

[StephanTLavavej]

I think it was worth a try, but given the effort we've discovered this will take to ship in production, against the possible user benefit (which I think is minimal, even though I am a huge fan of deprecation in general), I would prefer to close this PR; this will free up time for features and more important improvements. However, I would welcome a vNext enhancement issue to simply remove the primary template (that's a perfect kind of vNext issue since the product change is so simple).