#include <linalg> causes compiler error in VS2022

[QuantDevHacks]

Putting

#include <linalg>

in a source file in Visual Studio 2022, using the VS compiler, results in a compiler error. There is no error when I switch to the LLVM Platform Toolset in my project settings, however.

Details and repro follow:

My VS project name is lin_alg_examples (VS creates a directory of the same name). Under this directory, I created the following subdirectory:

...lin_alg_examples\kokkos\experimental

Under experimental, I placed the mdspan and linalg header files, and the _p0009bits and _p1673bits directories:

In the project settings, I am using the VS compiler with the latest C++ working draft:

I then write an empty main() function:

#include <experimental/mdspan>
#include <experimental/linalg>
#include <vector>#include <cstdlib>
#include <iostream>#include <format>
using std::vector, std::size_t, std::cout, std::format;
namespace stdex = std::experimental;
int main()
{

}

When I build the project, I get the following compiler error messages:

\lin_alg_examples\kokkos\experimental\__p1673_bits\transposed.hpp(255,57): error C2653: 'original_mapping_type': is not a class or namespace name

\lin_alg_examples\kokkos\experimental\__p1673_bits\transposed.hpp(253,17): message : This diagnostic occurred in the compiler generated function 'auto std::experimental::__p1673_version_0::linalg::impl::transposed_layout<std::experimental::layout_stride>::mapping(const std::experimental::layout_stride::mapping<Extents> &)'

It identifies lines 253 and 255 in transposed.hpp; lines 252-255 are as follows:

    template<class OriginalExtents>
    static auto mapping(const typename layout_stride::template mapping<OriginalExtents>& orig_map) {
      using original_mapping_type = typename layout_stride::template mapping<OriginalExtents>;
      using extents_type = transpose_extents_t<typename original_mapping_type::extents_type>;

I tried inserting the "ugly hack" referenced in Issue #242, but this did not fix the problem, even though it seemed it might be related.

If I comment out #include <experimental/linalg>, however, the project builds successfully.

Furthermore, if I restore the file so that the linalg file is included again, and I change the compiler Platform Toolset to the LLVM setting:

the code will compile successfully.

One final remark is that the exact same behavior is seen after changing the C++ Language Standard setting to C++20:

[mhoemmen]

@QuantDevHacks Thanks for reporting! Regarding the "ugly hack," I have a PR pending with the MSVC work-around: https://github.com/kokkos/stdBLAS/issues/242 . You mentioned that you tried a fix for it, so I'm guessing that the above PR won't help you -- though it's certainly worth a try.

I checked out that PR's branch. Then, I created a file include_linalg.cpp with the contents from your test (see below) in the compilation_tests directory. I also added add_compilation_test(include_linalg) to the end of CMakeLists.txt in that directory). The result built just fine.

#include <experimental/mdspan>
#include <experimental/linalg>
#include <vector>
#include <cstdlib>
#include <iostream>
#include <format>

using std::vector, std::size_t, std::cout, std::format;
namespace stdex = std::experimental;
int main()
{

}

I then rebuilt with the CMake option CMAKE_VERBOSE_MAKEFILE set to ON. This showed me the include paths (that follow the /I option of CL.exe). The ...\src directory contains the source code, and the ...\bld directory is the build directory (in which I ran CMake, in out-of-source fashion).

• ...\bld\kokkos\stdBLAS\include\experimental
• ...\src\kokkos\stdBLAS\include
• ...\bld\kokkos\stdBLAS\_deps\mdspan-src\include

I noticed also that I was using /std:c++latest. This is because I'm building using stdBLAS's CMake-based build system, and it picks the compiler options automatically for me.

The CMake build system for stdBLAS automatically downloads mdspan for you if you don't specify a path for it. It pulls from the stable branch of the usual mdspan git repository https://github.com/kokkos/mdspan.git . If you got the same headers, then I'm guessing that your include paths are different.

Another thing that could be happening is that since you're not running stdBLAS's CMake build process, then you're not getting its CMake-generated linalg_config.h file. You can find it in the stdBLAS build directory under include/experimental/__p1673_bits. That file looks like this for me.

#pragma once

/* #undef LINALG_ENABLE_ATOMIC_REF */
/* #undef LINALG_ENABLE_BLAS */
#define LINALG_ENABLE_CONCEPTS
/* #undef LINALG_ENABLE_KOKKOS */
/* #undef LINALG_ENABLE_KOKKOS_DEFAULT */

If you have /std:c++latest defined, then you probably also need LINALG_ENABLE_CONCEPTS defined.

In general, I'm not sure what happens if you just include the headers directly, instead of letting CMake install them. We don't test that use case.