fix: nested namespace holding kk mkl implementation

[maartenarnst]

This PR fixes a compilation error when compiling Trilinos/kokkos-kernels when both mkl and rocsparse are enabled.

Compilation errors look like this:

/Trilinos-sources/packages/kokkos-kernels/sparse/tpls/KokkosSparse_spmv_bsrmatrix_tpl_spec_decl.hpp:35:7: error: no member named 'mode_kk_to_mkl' in namespace 'KokkosSparse::Experimental::Impl::KokkosSparse::Impl'; did you mean '::KokkosSparse::Impl::mode_kk_to_mkl'?

The fix is to add a :: so as to look for KokkosSparse::Impl explicitly in the global namespace.

[kokkos-devops-admin]

Status Flag 'Pre-Test Inspection' - - This Pull Request Requires Inspection... The code must be inspected by a member of the Team before Testing/Merging
NO INSPECTION HAS BEEN PERFORMED ON THIS PULL REQUEST! - This PR must be inspected by setting label 'AT: PRE-TEST INSPECTED'.

[lucbv]

@maartenarnst sorry for the slow comment here... why not use a non qualified name instead of using this fully qualified one since we are in the same namespace? I think that would look cleaner...

[lucbv]

Suggested change

	::KokkosSparse::Impl::mkl_internal_safe_call(call, #call, __FILE__, __LINE__)
	mkl_internal_safe_call(call, #call, __FILE__, __LINE__)

[maartenarnst]

I'm not sure. I agree that the macro is defined here in a piece of code inside the KokkosSparse::Impl namespace. But, then, when the macro is used somewhere else, this namespace is not taken with it.

E.g. when it's used here

• kokkos-kernels/sparse/src/KokkosSparse_spgemm_handle.hpp

  Lines 240 to 242 in afd65f0

  	~mklSpgemmHandleType() {
  	KOKKOSKERNELS_MKL_SAFE_CALL(mkl_sparse_destroy(C));
  	}

it's called in a piece of code in the KokkosSparse namespace without the Impl. So shouldn't we keep the proposed change?

[lucbv]

Good point this would obviously create issues. Would you mind moving the definition of the macro KOKKOSKERNELS_MKL_SAFE_CALL to line 232, just after the namespaces are closed?
My suspicion is at that point the leading :: in your fix might not be needed anymore?

[lucbv]

I opened PR #2134 that fixes the issue in a way that I find cleaner, let me know if you have an issues closing this?

[lucbv]

@maartenarnst can you see if your issues are resolved with PR #2134 being merged now?
I will close this and maybe create an issue instead to track the problem further if there is still a build problem on your end.