[ci] Update GitHub Action Jimver/cuda-toolkit to 0.2.35

[gruenich]

Fix another deprecation warning that Node20.js will stop workin in June

No pull request can be accepted unless you first sign the Contributor License Agreement (see the PDF agreement in the Contributor_License folder). Sign the PDF and email it to me (digital signature OK). Submit all PRs to the dev2 branch only.

[DrTimothyAldenDavis]

It looks like this breaks the mingw builds. The clang 64-bit builds fail as shown below but this is something I can quickly fix. The typecast here is safe. I can patch that here by adding a (GB_void *) typecast to the S_input parameter. I'll need to make the related change in my dev2 branch of GraphBLAS, however, since the SuiteSparse copy of GraphBLAS is the latest stable one, not my development branch for GraphBLAS.

I'm not sure why the mingw32 should fail; it was working before but it didn't fine the openblas64 library somehow.

CMakeFiles/GraphBLAS.dir/Source/extract/GB_I_inverse.c.obj -c C:/a/SuiteSparse/SuiteSparse/GraphBLAS/Source/extract/GB_I_inverse.c
  C:/a/SuiteSparse/SuiteSparse/GraphBLAS/Source/extract/GB_I_inverse.c:123:9: error: incompatible pointer types passing 'uint64_t[1]' (aka 'unsigned long long[1]') to parameter of type 'const GB_void *' (aka 'const unsigned char *') [-Wincompatible-pointer-types]
    123 |         S_input,            // values of R (iso-valued)
        |         ^~~~~~~
  C:/a/SuiteSparse/SuiteSparse/GraphBLAS/Source/builder/GB_build.h:50:29: note: passing argument to parameter 'S_input' here
     50 |     const GB_void *restrict S_input,// array of values of tuples, size nvals,
        |                             ^
  1 error generated.

[DrTimothyAldenDavis]

The clang64 failure is very strange since this PR shouldn't affect that. Maybe the clang version update is what broke this, from an earlier change to the workflow. In any case, it's a quick fix. Not sure what to do about the mingw32 broken workflow. Both of these workflow failures are very strange.

[DrTimothyAldenDavis]

See my dev2 branch of GraphBLAS ... I already fixed the S_input typecast there, about a month ago:

DrTimothyAldenDavis/GraphBLAS@c4e8f7f

I can either update SuiteSparse/GraphBLAS to my latest dev2 version on the GraphBLAS repo, or perhaps just patch this one line so the workflow passes.

[DrTimothyAldenDavis]

See 8e48c98 for the 1-line patch.

I'll rerun the workflow

[gruenich]

• Regarding the mingw32 failure, I already created issue CodeQL breaks because mingw-w64-i686-openblas package does not longer exist #1031.
• If you prefer, I can close this pull request and create it for GraphBLAS. Tell me what you prefer and I will do so tomorrow.

[DrTimothyAldenDavis]

Regarding the opeblas failure on mingw: GraphBLAS doesn't use any dense blas at all, in spite of the name of the package. So this is best fixed in SuiteSparse itself.

yes, I think it would make sense to drop that particular test, or perhaps to change to a different BLAS package. SuiteSparse requires some kind of BLAS package for UMFPACK, CHOLMOD, and SPQR.

[DrTimothyAldenDavis]

So don't close this issue; I'd like to figure out how to resolve it.

[mmuetzel]

The 32-bit environments have been deprecated in MSYS2:
https://www.msys2.org/news/#2023-12-13-starting-to-drop-some-32-bit-packages

Since that announcement, the CLANG32 environment has already been removed entirely:
https://www.msys2.org/news/#2024-12-18-removal-of-the-clang32-environment

More and more packages are also being dropped for the MINGW32 environment.

It is probably ok to remove the CI configuration for the MINGW32 environment from MSYS2 for SuiteSparse. There are other workflows that are testing if building for 32-bit targets keeps working if I recall correctly.

[gruenich]

I created #1033 to replace mingw32 by mingw64 for GraphQL. The workflow needs a manual run for the GraphQL workflow for my branch.

[DrTimothyAldenDavis]

Looks great -- thanks!