Making KDevelop understand CUDA files

[Thomas Schöps]

Hi KDevelop developers,

I attempted to get KDevelop to understand CUDA code. I got it working
on my system, but unfortunately it seems difficult to make it work in
general. I though I'd share my experience here in case somebody is
interested.

I proposed a patch ( https://phabricator.kde.org/D17909 ) that makes
KDevelop handle CUDA .cu / .cuh files better. I also proposed a patch
( https://phabricator.kde.org/D17904 ) to KTextEditor's syntax
highlighting library which makes it treat .cu / .cuh files as C++ by
default. Unfortunately, there are more issues though:

1) KDevelop needs to use a very recent version of clang to support new
CUDA versions. For example, the current CUDA 10 does not seem to be
supported by any stable clang release at the moment yet ( c.f.
Prerequisites section at
https://llvm.org/docs/CompileCudaWithLLVM.html ). In my case, I am
using CUDA 9.1, and I compiled clang 7 myself to have it supported
(the default on my system seemed to be clang 6, I think).

2) There are different ways to install CUDA, and clang only supports
the directory structure as created by Nvidia's installer package (
also, c.f. Prerequisites section at
https://llvm.org/docs/CompileCudaWithLLVM.html ). If CUDA is installed
using a distribution package, the directory structure might differ,
and clang will not find it. It is possible to work around this by
creating symlinks to mimic the installer package's directory
structure. But automating this might require handling each
distribution separately. In my case, I use Ubuntu 18.04 and CUDA 9.1,
and I created the symlinks as follows:
sudo mkdir /usr/local/cuda-9.1-shim
sudo ln -s /usr/local/cuda-9.1-shim /usr/local/cuda-9.1
sudo ln -s /usr/local/cuda-9.1-shim /usr/local/cuda
sudo ln -s /usr/lib /usr/local/cuda-9.1/lib64
sudo ln -s /usr/include /usr/local/cuda-9.1/include
sudo ln -s /usr/bin /usr/local/cuda-9.1/bin
sudo mkdir /usr/local/cuda-9.1/nvvm
sudo ln -s /usr/lib/nvidia-cuda-toolkit/libdevice
/usr/local/cuda-9.1/nvvm/libdevice
sudo ln -s /usr/lib/cuda/version.txt /usr/local/cuda-9.1/version.txt

3) Initially, clang didn't find math.h when parsing cmath, since it is
included with #include_next instead of #include, which apparently
prevented finding the file. This issue similarly applied to three
system headers in total. I worked around this on my system in a very
dirty way by replacing the #include_next statements with #include in
these system headers. A proper fix would be to add for example
-isystem /usr/include/c++/7.3.0 to the compile options. But I wasn't
aware how to best determine which specific directory (version) to add.
Notice that for compiling CUDA files, projects are likely to use the
nvcc CUDA compiler instead of clang, with which this problem does not
occur for the project I tested it on.

4) When KDevelop parsed CUDA files with libclang, I initially got a
lot of errors about missing internal functions such as
__nv_tex_surf_handler(), __nvvm_read_ptx_sreg_tid_x(),
__nvvm_read_ptx_sreg_tid_y(), etc. (These don't show up in the
problems toolview since they are in external header files and thus
filtered out, but they seemingly prevent full parsing of included
headers, which likely causes unrelated definitions to be missing,
which eventually causes seemingly unrelated parsing errors in the
source file.) When I tried to invoke clang with the same options as
used for parsing externally, it seemed to work. Thus I don't know
where this issue comes from, but it can be worked around by adding a
dummy macro for each missing function in the defines file (-imacros)
passed to libclang that simply defines them to some constant ( e.g.
"#define __nvvm_read_ptx_sreg_tid_x(...) 0"). Unfortunately, I think
that this list of functions likely changes for each CUDA release, and
I'm not sure whether my list is even complete for the version I use.

After working around all of these issues, KDevelop's code
understanding seems to work fine for me now for CUDA files. But in
this form it unfortunately requires some manual effort to get it
working.

Best regards,
Thomas