Request: CUDA linting

[sunbubble]

CUDA is a C++ extension for GPU programming.
Modern versions of Clang can compile it, provided you also have the Nvidia CUDA-toolkit installed, which also includes a fully functioning compiler NVCC.
Clang warnings and error messages are, as expected, superior.

So I request support for both:

• NVCC
• Clang (http://llvm.org/docs/CompileCudaWithLLVM.html)

CUDA file extensions are *.cu and *.cuh (although for headers *.h and *.hpp are also common)

Thank you

[w0rp]

If anyone has experience with CUDA and VimL, feel free to open a pull request. (Especially one with documentation and Vader tests.)

[lucaskolstad]

I made an attempt at this for both and there was an implementation issue for each:

1. nvcc doesn't seem to accept input through stdin through any of the usual ways. If someone has an example how to do this, if it can do it, that would be helpful as it is a non-starter otherwise. It's required for handlers in ale.

2. For the clang++ option, it is complicated by management of the cuda paths, but could work. It works for me using just the quick example implementation in PR Add CUDA linter using clang #442, but
   that is because I have my CUDA install symlinked to /usr/local/cuda on my machine from where it was installed by my package manager into /opt/cuda. clang++ just detects it automatically in that case and can find the headers and such to do the linting.

   Any user who doesn't have their CUDA paths set up properly, would have to pass options to g:ale_cuda_clang_options to fix that by hand. Those options would be things like --cuda-path=/opt/cuda or more directly with typical link and include options.

   If a user doesn't have this set up properly we could not detect it and would not know to not run our clang++ linter. All we check for before running it is that we are in a file with ft == cuda and that clang++ is available. We would just get an invisible linter error every time in the background like this:

   clang-3.9: error: cannot find CUDA installation. Provide its path via --cuda-path, or pass -nocudainc to build without CUDA includes.
   

   If a user doesn't have cuda installed at all, they would get the same background error with the linter as if the cuda paths were not set up correctly.

   Now, I am no CUDA expert so I am unsure how common this would be for people who use ale and open cuda files to not have their cuda paths set up. It's pretty ugly to know there is a case where we would waste CPU time asking clang++ to fail to find the CUDA installation over and over in the background.

[lucaskolstad]

We could check a few likely spots for the installation like /usr/local/cuda and /opt/cuda and add --cuda-path=/usr/local/cuda if we find it. However that is not very robust for two reasons:

1. Any directory by that name which isn't actually a cuda install would break it.
2. If a user has multiple cuda versions installed and we look for one and choose, it may contradict their expectations of which version should get picked if they expected whatever clang++ was going to default to.

Or perhaps we could have a mandatory variable g:ale_cuda_clang_cudapath that must be set in order for the CUDA linter to run at all? That would basically be equivalent leaving it disabled by default and only enabling it if the user explicitly tells us what CUDA install to use.

[w0rp]

Sorry that not that much progress has been made on this. I'm not too familiar with Cuda myself, so I'm not sure what to advise.

Have to manually configure the path for Cuda might be acceptable, if it's not possible to search for a path. If you return an empty string from either a callback for the command or the executable, then ALE will skip that linter. So you can return an empty string when you can't run anything.

[w0rp]

I'll leave this to someone who knows how to work with CUDA.

[hsanson]

This seems to have been added already? not familiar enough with CUDA to know for sure: #3598

[oToToT]

I think this is actually added. At least, ale would generate error from nvcc for me.