Fix overflow in complex //

[nhz2]

Fixes #53435

With this change, internal calculations may still throw an OverflowError even if the true result would not overflow, but I think this is better than the current behavior of returning the wrong result:

julia> (Int8(-128) + Int8(-81)im) // (Int8(-42) + Int8(63)im)
ERROR: OverflowError: 63 * 3 overflowed for type Int8
Stacktrace:
 [1] throw_overflowerr_binaryop(op::Symbol, x::Int8, y::Int8)
   @ Base.Checked ./checked.jl:164
 [2] checked_mul
   @ ./checked.jl:298 [inlined]
 [3] //(x::Complex{Int8}, y::Complex{Int8})
   @ Base ./rational.jl:124
 [4] top-level scope
   @ REPL[23]:1

julia> (-128 + -81im) // (-42 + 63im)
1//21 + 2//1*im

Simple benchmarks:

using Chairmarks
@b (rand(1:1000), complex(rand(1:1000), rand(1:1000))) x->//(x...) seconds=1
@b (complex(rand(1:1000), rand(1:1000)), complex(rand(1:1000), rand(1:1000))) x->//(x...) seconds=1

master: 16.122 ns, 59.158 ns
PR: 12.720 ns, 15.447 ns

Edit: I added a suggestion from #60137 so now this PR also fixes #60137 and fixes #56245

[adienes]

internal calculations may still throw an OverflowError even if the true result would not overflow,

some @test_brokens for those would be good too probably

[nhz2]

It would be easy to solve all of these overflows by converting to BigInt, but is this worth the performance cost? Overflow errors seem to be an inherent part of doing math with many intermediate steps with Rational{Int}.

[adienes]

I wouldn't say promoting to BigInt is necessary, no.

the fact that something like 3.0 // (1 + 1im) now MethodErrors is in my opinion the correct outcome, but maybe it is worth running PkgEval to check that nobody is accidentally relying on that, and we can give them a polite warning?

[nhz2]

@nanosoldier runtests()

[nanosoldier]

The package evaluation job you requested has completed - possible new issues were detected.
The full report is available.

Report summary

❗ Packages that crashed

10 packages crashed on the previous version too.

✖ Packages that failed

17 packages failed only on the current version.

• Package fails to precompile: 1 packages
• Illegal method overwrites during precompilation: 1 packages
• Package has test failures: 5 packages
• Package tests unexpectedly errored: 4 packages
• Tests became inactive: 1 packages
• Test duration exceeded the time limit: 5 packages

1503 packages failed on the previous version too.

✔ Packages that passed tests

5 packages passed tests only on the current version.

• Other: 5 packages

5415 packages passed tests on the previous version too.

~ Packages that at least loaded

1 packages successfully loaded only on the current version.

• Other: 1 packages

3281 packages successfully loaded on the previous version too.

➖ Packages that were skipped altogether

902 packages were skipped on the previous version too.

[adienes]

looks like main problem is new ambiguities with methods of //(<:Number, ::Complex)

[adienes]

@nanosoldier runtests(["Unitful", "CliffordNumbers", "MultiplesOfPi"])

[nhz2]

There is one remaining test failure in MultiplesOfPi.jl
CC @jishnub
I think the Pi^-1 needs to be switched to Pi^Int(-1) or 1//Pi to prevent promoting to Float64

julia> (Pi^-1) |> typeof
PiExpTimes{Float64, Int64}

julia> (Pi^Int(-1)) |> typeof
PiExpTimes{Int64, Int64}

Complex{Int}: Error During Test at /home/nathan/.julia/packages/MultiplesOfPi/QLHYm/test/runtests.jl:498
  Test threw exception
  Expression: Pi ^ -1 // (2im) === (0 // 1 - 1 // 2 * im) * Pi ^ -1
  MethodError: no method matching //(::Float64, ::Int64)
  The function `//` exists, but no method is defined for this combination of argument types.
  Closest candidates are:
    //(::Number, ::Complex)
     @ Base rational.jl:128
    //(::Complex, ::Real)
     @ Base rational.jl:107
    //(::LinearAlgebra.UniformScaling, ::Number)
     @ LinearAlgebra ~/github/julia/usr/share/julia/stdlib/v1.14/LinearAlgebra/src/uniformscaling.jl:290
    ...
  Stacktrace:
    [1] //(p::PiExpTimes{Float64, Int64}, y::Int64)
      @ MultiplesOfPi ~/.julia/packages/MultiplesOfPi/QLHYm/src/MultiplesOfPi.jl:255
    [2] //(x::Complex{PiExpTimes{Float64, Int64}}, y::Int64)
      @ Base ./rational.jl:107
    [3] //(x::PiExpTimes{Float64, Int64}, y::Complex{Int64})
      @ Base ./rational.jl:130

[nanosoldier]

The package evaluation job you requested has completed - possible new issues were detected.
The full report is available.

Report summary

✖ Packages that failed

1 packages failed only on the current version.

• Package tests unexpectedly errored: 1 packages

✔ Packages that passed tests

2 packages passed tests on the previous version too.

[adienes]

lgtm then, I think just that test should be fixed. I'll leave this up for a few days in case anybody else has thoughts (maybe @nsajko , as the author of #56245 ?) and merge closer to the end of the week