[BUG]: Windows build failure

[mfbalin]

Is this a duplicate?

• I confirmed there appear to be no duplicate issues for this bug and that I agree to the Code of Conduct

Type of Bug

Compile-time Error

Component

Not sure

Describe the bug

10>C:\Users\Muhammed Fatih Balin\dgl-1\third_party\thrust\dependencies\libcudacxx\include\cuda\std\detail/libcxx/include/type_traits(4333): error : "cuda" is ambiguous [C:\Users\Muhammed Fatih Balin\dgl-1\build\dgl.vcxproj] cuda::std::__4::__invoke(cuda::std::__4::declval<_XFp>(), cuda::std::__4::declval<_XArgs>()...)); ^ detected during: instantiation of class "cuda::std::__4::__invokable_r<_Ret, _Fp, _Args...> [with _Ret=void, _Fp=dgl::aten::impl::<unnamed>::IndptrFunc<int 32_t>, _Args=<signed int>]" at line 4400 instantiation of class "cuda::std::__4::__invoke_of<_Fp, _Args...> [with _Fp=dgl::aten::impl::<unnamed>::IndptrFunc<int32_t>, _Args=<signe d int>]" at line 4423 instantiation of class "cuda::std::__4::invoke_result<_Fn, _Args...> [with _Fn=dgl::aten::impl::<unnamed>::IndptrFunc<int32_t>, _Args=<sig ned int>]" at line 4428 instantiation of type "cuda::std::__4::invoke_result_t<dgl::aten::impl::<unnamed>::IndptrFunc<int32_t>, signed int>" at line 699 of C:/Use rs/Muhammed Fatih Balin/dgl-1/third_party/thrust\thrust/detail/type_traits.h instantiation of type "dgl::thrust::detail::invoke_result_t<dgl::aten::impl::<unnamed>::IndptrFunc<int32_t>, signed int>" at line 41 of C: /Users/Muhammed Fatih Balin/dgl-1/third_party/thrust\thrust/detail/type_traits/result_of_adaptable_function.h [ 2 instantiation contexts not shown ] instantiation of class "dgl::thrust::detail::eval_if<true, Then, Else> [with Then=dgl::thrust::detail::result_of_adaptable_function<dgl::a ten::impl::<unnamed>::IndptrFunc<int32_t> (signed int), void>, Else=dgl::thrust::detail::identity_<dgl::thrust::use_default>]" at line 49 of C:/Users/ Muhammed Fatih Balin/dgl-1/third_party/thrust\thrust/iterator/detail/iterator_adaptor_base.h instantiation of class "dgl::thrust::detail::ia_dflt_help<T, DefaultNullaryFn> [with T=dgl::thrust::use_default, DefaultNullaryFn=dgl::thr ust::detail::result_of_adaptable_function<dgl::aten::impl::<unnamed>::IndptrFunc<int32_t> (signed int), void>]" at line 44 of C:/Users/Muhammed Fatih Balin/dgl-1/third_party/thrust\thrust/iterator/detail/transform_iterator.inl instantiation of class "dgl::thrust::detail::transform_iterator_base<UnaryFunc, Iterator, Reference, Value> [with UnaryFunc=dgl::aten::imp l::<unnamed>::IndptrFunc<int32_t>, Iterator=dgl::thrust::counting_iterator<int32_t, dgl::thrust::use_default, dgl::thrust::use_default, dgl::thrust::u se_default>, Reference=dgl::thrust::use_default, Value=dgl::thrust::use_default]" at line 190 of C:/Users/Muhammed Fatih Balin/dgl-1/third_party/thrus t\thrust/iterator/transform_iterator.h instantiation of class "dgl::thrust::transform_iterator<AdaptableUnaryFunction, Iterator, Reference, Value> [with AdaptableUnaryFunction=d gl::aten::impl::<unnamed>::IndptrFunc<int32_t>, Iterator=dgl::thrust::counting_iterator<int32_t, dgl::thrust::use_default, dgl::thrust::use_default, d gl::thrust::use_default>, Reference=dgl::thrust::use_default, Value=dgl::thrust::use_default]" at line 564 of C:\Users\Muhammed Fatih Balin\dgl-1\src\ array\cuda\labor_sampling.cu instantiation of "std::pair<dgl::aten::COOMatrix, dgl::IdArray> dgl::aten::impl::CSRLaborSampling<XPU,IdType,FloatType>(dgl::aten::CSRMatr ix, dgl::IdArray, int64_t, dgl::FloatArray, int, dgl::IdArray, float, dgl::IdArray) [with XPU=kDGLCUDA, IdType=int32_t, FloatType=float]" at line 819 of C:\Users\Muhammed Fatih Balin\dgl-1\src\array\cuda\labor_sampling.cu

How to Reproduce

template <typename IdType>
struct IndptrFunc {
  const IdType* indptr;
  const IdType* in_deg;
  __host__ __device__ auto operator()(IdType row) {
    return indptr[row] + (in_deg ? in_deg[row] : 0);
  }
};

auto b_offsets = thrust::make_transform_iterator(
        iota, IndptrFunc<IdType>{indptr.get(), nullptr});

Fails to compile with MSVC, "Visual Studio 17 2022", with NVCC. This code snipped is from https://github.com/dmlc/dgl/blob/master/src/array/cuda/labor_sampling.cu#L564. We hit this compilation error with the latest CCCL main branch.

Expected behavior

There shouldn't be a difference whether we compile with MSVC or GCC.

Reproduction link

No response

Operating System

No response

nvidia-smi output

No response

NVCC version

PS C:\Users\Muhammed Fatih Balin\dgl-1\build> nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2023 NVIDIA Corporation
Built on Tue_Jul_11_03:10:21_Pacific_Daylight_Time_2023
Cuda compilation tools, release 12.2, V12.2.128
Build cuda_12.2.r12.2/compiler.33053471_0

[jrhemstad]

@miscco could you take a look into this?

[Rhett-Ying]

Thanks for opening this ticket. Here's the ticket in DGL: #327 More details could be found there.

[miscco]

Thanks for opening this ticket. Here's the ticket in DGL: #327 More details could be found there.

Hi @Rhett-Ying , I believe you linked this exact issue

[miscco]

So I have been digging a bit. Looking at this comment in the original issue it looks like some namespace issues

dmlc/dgl#6139 (comment)

The error starts with:

>C:\Users\Muhammed Fatih Balin\dgl-1\third_party\cccl\libcudacxx\include\cuda\std\detail\libcxx\include\__functional/invoke.h(413):
        error : "cuda" is ambiguous [C:\Users\Muhammed Fatih Balin\dgl-1\build\dgl.vcxproj]

This seems dubious and hints to some namespace issues, where cuda is a subnamespace. I believe we can fix this issue by changing our internal _CUDA_VSTD macro to always use global qualification ::cuda::std:: instead of relative qualification cuda::std as we are doing right now. I have opened a PR for that #331.

The other issue I am seeing in the comments is related to tuple and MSVC 2017.

I spend some time making our internal tests pass with MSVC2017. One of the main issues was that the way we historically handle constraints checks via nested structs is broken there (and also super complicated)

We did cleanup optional and expected and I could give tuple a similar run, but that would involve a lot of work

[jrhemstad]

Yeah, looks like you're right @miscco about the cuda:: namespace usage, e.g., https://github.com/dmlc/dgl/blob/346410928f6a3a5d735ed3b0902fb4f8d74063c6/src/array/cuda/spmm_hetero.cu#L90

In combination with this: https://github.com/dmlc/dgl/blob/346410928f6a3a5d735ed3b0902fb4f8d74063c6/src/array/cuda/spmm_hetero.cu#L15

That's a recipe for very bad things.

[mfbalin]

Looks like #331 fixed the compilation issue for DGL. Thanks for the swift assistance!

[miscco]

That is awesome to hear. The fix is not in main yet, only our 2.2 branch, so I will keep that issue open until it is merged into main

[mfbalin]

Is there a timeline for when the 2.2 release is going to be announced?

[jrhemstad]

Hey @mfbalin, apologies for not following up sooner. The 2.2 release has been available for a while now here: https://github.com/NVIDIA/cccl/releases/tag/v2.2.0

[Rhett-Ying]

@jrhemstad thanks for your update.