fix: use portable binding argument types

[IvanaGyro]

Problem

Several small C++ type assumptions were portable on the existing Unix builds but fail with MSVC:

• the Python bindings use the POSIX global ssize_t, which MSVC does not define;
• permute_nosignflip accepts label literals through a mutable char * initializer list;
• Reference LAPACK 3.11's lapacke.h includes lapack.h directly, so defining LAPACK_COMPLEX_CPP without loading lapacke_config.h still leaves determinant code with non-portable C99 _Complex types;
• after selecting LAPACKE's C++ types, one non-MKL utility still hard-coded GNU __complex__ pointers instead of following lapack_complex_float/double.

Fix

• provide an MSVC-only ssize_t compatibility alias using the signed counterpart of std::size_t, while preserving the native POSIX type elsewhere;
• use std::initializer_list<const char *> for label literals and convert them to std::string without a test-only overload workaround;
• define LAPACK_COMPLEX_CPP, include lapacke_config.h before lapacke.h, and keep determinant buffers as C++ complex values;
• make the real-to-complex copy helper use the LAPACKE-selected pointer types rather than compiler-specific complex types.

These are type-portability fixes only; dtype IDs, public behavior, copy behavior, and determinant arithmetic are unchanged.

Validation

• clang-format 14.0.6 dry-run passes for the changed C++ files;
• an MSVC 19.44 probe against the exact Reference LAPACK v3.11.0 headers proves the old include order fails on float/double _Complex, while the new order compiles and maps both LAPACK complex types to std::complex;
• a repository audit found no other live C99/GNU complex pointer assumptions; all other LAPACKE complex callers already use lapack_complex_*;
• the touched Complexmem_cpu.cpp object compiles incrementally with MSVC in the existing Ninja tree;
• the existing MSVC/Ninja build directory previously relinked cytnx, the CPython 3.10 module, and test_main incrementally;
• focused determinant validation passes: 6 tests, including all real and complex dtypes;
• the Windows Python suite for the binding changes passed previously: 308 passed, 1 skipped.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[codecov]

⚠️ JUnit XML file not found

The CLI was unable to find any JUnit XML files to upload.
For more help, visit our troubleshooting guide.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 45e3ae4d68

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Configure LAPACKE in every translation unit

When building the non-MKL backend with MSVC against Reference LAPACK 3.11, this configuration remains local to translation units that include lapack_wrapper.hpp; src/Type.cpp:17 still includes <lapacke.h> directly, so lapack.h encounters its default C99 _Complex declarations and the cytnx target fails to compile. Apply the complex configuration to that direct include as well (or make it a target-wide setting) so the intended MSVC fix covers the complete build.

Useful? React with 👍 / 👎.

[ianmccul]

set HAVE_LAPACK_CONFIG_H and LAPACK_COMPLEX_CPP in cmake

[IvanaGyro]

MSCV successfully builds because complex types are not used in that translation unit. src/Type.cpp:17 includes <lapacke.h> to define __blasINTsize__, which is not used everywhere. Open issue #1115 for tracing this issue.

[yingjerkao]

By MSVC you mean native Windows support? I thought we only support WSL?

[yingjerkao]

I would recommend that we do not start building native Windows wheels at this point since I don't see a large user base here. I believe the priority should be given to stabilize the C++ API.

[ianmccul]

I don't know anything about windows (have not used it since windows 98), but the changes here look generally good anyway.

It is worth setting HAVE_LAPACK_CONFIG_H and LAPACK_COMPLEX_CPP in cmake, OR have some common cytnx header that defines these before including lapacke.h, and make sure that all cytnx code that uses lapack-related identifies includes the cytnx lapack header and does not include lapacke.h directly.

[IvanaGyro]

I would recommend that we do not start building native Windows wheels at this point since I don't see a large user base here. I believe the priority should be given to stabilize the C++ API.

I start to build with MSVC because I am on Windows. I thought it will be convenient for codex desktop app if cytnx can be built on Windows, and Windows also support CUDA. If we explicitly do not want to support Windows, we only need to remove Type.hpp change in this PR.

[yingjerkao]

I would recommend that we do not start building native Windows wheels at this point since I don't see a large user base here. I believe the priority should be given to stabilize the C++ API.

I start to build with MSVC because I am on Windows. I thought it will be convenient for codex desktop app if cytnx can be built on Windows, and Windows also support CUDA. If we explicitly do not want to support Windows, we only need to remove Type.hpp change in this PR.

If that is the case, I will approve the PR chain.