Test_AssertEqual_Complex.pf: some AssertEqual overloads unresolvable after enabling REAL64/REAL128 guards

[djkees]

While fixing #574 (REAL32/64/128 test-coverage guards), tests/funit-core/Test_AssertEqual_Complex.pf couldn't be included: applying the same #ifdef _REAL32/_REAL64/_REAL128 → _ISO_REAL* guard fix there activates code that fails to compile with gfortran. Confirmed failures include both array-form and scalar assertions, e.g.:

@assertEqual([a_64,b_64], [a_64,b_64])
@assertEqual([a_128,b_128], [a_128,b_128])
@assertEqual(a_128, a_128)   ! some scalar REAL128 calls in this same block also fail

with:

Error: There is no specific subroutine for the generic 'assertequal' at (1)

This happens even though a matching procedure appears to exist in the generated interface (src/funit/asserts/AssertComplex_1d.F90):

interface AssertEqual
   ...
   module procedure AssertEqual_COMPLEX64_1d_COMPLEX64_1d_Real_0d
   ...
end interface

with tolerance correctly declared optional:

subroutine AssertEqual_COMPLEX64_1d_COMPLEX64_1d_Real_0d(expected, actual, tolerance, message, location)
   complex (kind=REAL64), intent(in) :: expected (:)
   complex (kind=REAL64), intent(in) :: actual (:)
   real (kind=kind(1.)), optional, intent(in) :: tolerance
   ...

I ruled out a plain compiler limitation with a standalone reproduction of the same shape (a generic interface with two specific procedures differing only by the kind of an optional argument) — that compiles fine on its own with the same gfortran version. So this looks like a real defect specific to Assert_Complex.tmpl's overload generation, or to how pf_AssertOverloads aggregates the per-rank AssertEqual generics from AssertComplex_{rank}d, AssertReal_{rank}d, etc. — not yet root-caused further.

gfortran reports failures at both rank-0 (scalar) and rank-1 (array) call sites in this file; exact line attribution for some of the scalar failures is imprecise (gfortran attributes a couple of them to blank lines / end subroutine near the #ifdef block boundaries rather than the specific @assertEqual call), but the errors are clearly within the REAL64/REAL128 scalar blocks of test_equal_scalar and test_equal_scalar_with_tolerance.