Cleanup Wrappers and Tests

[alyst]

This is a subset of #30 excluding the Matrix * SparseMatrix:

• adds support for MKL 2023.x
• simplifies the MKLSparse wrappers by introducing mkl_call(funcname, T, args...) generated function that automatically transforms templates like mkl_Tcscmv into appropriate MKLSparse function names for a specific input types (e.g. mkl_dcscmv).
• @eval-based generation of all possible wrapper method parameter combinations is replaced by a single method with a proper signature and the use of mkl_call() that automatically generates a proper method MKLSparse method name to call. That should make debugging and code coverage analysis easier.
• some unnecessary "type piracy" of Base.* was removed, I've also added comments explaining the motivation for specific LinearAlgrebra/Base (re)definitions
• fixes 4-arg ldiv!() from ldiv!(a, A, B, C) to ldiv!(C, A, B, a) to be compatible with 3-arg ldiv!() already in Base (AFAIK 4-arg is only defined in MKLSparse). This would break any packages/script that use MKLSparse.jl 4-arg ldiv!(), but this should be a rather exotic case.
• streamlines testing, so that all combination of sparse matrix value, index types, storage as well as triangular, symmetric, adjoint and transposed are covered
• @test_blas macro replaced by conventional @test macro in combination with @blas macro that allows more fine-grained checks of whether Sparse BLAS MKL methods are being called
• in tests maximum(abs.(...)) <= eps is replaced with ≈ atol=...
• update CI.yml to use julia-actions
• enable code coverage

No new version of MKLSparse.jl was tagged after #31 got merged. It could be done before/after this PR.

[alyst]

@KristofferC Considering sparse*matrix failures on Julia nightly failures on macOS. The tests in this PR fails just as in #30.
It's interesting, though, when I am switching from Sparse BLAS API (see test results) to inspector/executor API, the amount of failures is 2x reduced. Also, when given the same input data and using the same SparseBLAS routine under the hood, the mul!(C, A, B, a, 0), mul!(C, A, B) and A * B alternatives fail or succeed randomly, and changes from run to run. Could it be something related to e.g. array memory management on Julia-nightly at macOS?

[codecov-commenter]

Codecov Report

❗ No coverage uploaded for pull request base (master@925146a). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #37   +/-   ##
=========================================
  Coverage          ?   10.41%           
=========================================
  Files             ?        6           
  Lines             ?     1258           
  Branches          ?        0           
=========================================
  Hits              ?      131           
  Misses            ?     1127           
  Partials          ?        0           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[alyst]

Either Julia nightly was fixed on macOS or with the given explicitly specified random seed the multiplication error does not manifest itself. I think the PR is ready for review.

cc @KristofferC

[amontoison]

@alyst I should be able to review the PR next week.

[rayegun]

Could we document this? It matches mul! so it's not entirely unexpected

[alyst]

You mean add the docstring?

[alyst]

bump. I would really appreciate if someone can review the PR :)

[ViralBShah]

@alyst Long pending here, but seems like we should get this merged if you still have the bandwidth for it.

[amontoison]

@alyst I have switched to the new API and generated all wrappers in src/libmklsparse.jl.
This should simplify your PR.

[alyst]

@amontoison Thank you! I've rebased this PR on top of the current master.
In comparison to the previous revision, I went further with the generated functions approach and completely replaced @eval-based wrappers generation (both for intermediate wrappers like mv!() and LinearAlgebra.jl overloads).
That should make it easier for debugging and coverage reports.

I've checked, and on 1.10.4 the @code_llvm mv!(...) output suggests that the generated function mkl_call() gets inlined (and so the exact name of the MKLSparse.lib function to call gets resolved at compile time).
So there should be no performance penalty for using the generated functions (at least for the repeated calls).

I've also updated the CI to use Julia actions. One thing that does not work is the upload of the coverage reports to the codecov: it needs a token, and I don't have access to modifying this repo secrets.

Would be nice if somebody reviews the PR before it becomes stale again.
Once it's merged, I'll rebase #30 so that MKLSparse.jl supports more combinations of input parameters for sparse linalg routines.

[amontoison]

Thanks @alyst !!
I will update the token for coverage reports.