Upgrade clang-tools to 21 to fix clangd SIGSEGV on CUDA files

[fwilliams]

Summary

• Upgrades clang-tools from 18 to 21 in the dev conda environment to fix a clangd crash (SIGSEGV) that occurs when building ASTs for .cuh files.
• The crash is a known clang 18 bug in CUDA host/device operator delete resolution, triggered by delete this; in GCC 13.4.0's locale_classes.h (std::locale::facet::_M_remove_reference). It is fixed in clang 21.
• Switches clang-format and clang specs to versioned package names (clang-format-18, clang-18) so they coexist with the clang-tools=21 dependency on clang-format=21. The clang-format-18 binary remains available as required by CI.

Motivation

clangd (shipped via clang-tools) crashes with a segmentation fault every time it tries to parse CUDA files that transitively include GCC's <locale> header (e.g. via PyTorch or standard library headers). This makes C++/CUDA language intelligence completely non-functional for affected files like GaussianCameras.cuh.

The crash stack trace:

Signalled during AST worker action: Build AST
Signal: SIGSEGV
clang::Sema::ActOnCXXDelete(...)
clang::Sema::MarkFunctionReferenced(...)

Upgrading to clang-tools 21 (which bundles clangd 21) resolves the crash since the underlying CUDA operator delete resolution bug was fixed upstream.

Test plan

• Verified clangd --check=src/fvdb/detail/ops/gsplat/GaussianCameras.cuh completes without crash on clangd 21
• Verified clang-format-18 --version still reports 18.1.8 after the environment rebuild
• Rebuild the conda environment from env/dev_environment.yml and confirm clangd no longer crashes on CUDA files
• Confirm CI passes (codestyle checks still use clang-format 18)

Made with Cursor

[harrism]

Why not use clang-tools 21 in CI as well?

[swahtz]

Why not use clang-tools 21 in CI as well?

I think what's being relayed is that we are leaving the 'C++ codestyle' action in codestyle.yml using clang-format 18. This is because clang-format's results can change (on purpose) between versions of clang-format so we've just standardized on using clang-format 18 (an argument to the DoozyX/clang-format-lint-action we use for the code style checking). Our .vscode/settings.json specifies clang-format-18 so it stays consistent with the CI checks.

[swahtz]

I tried it out and works well for me, thanks for fixing that up.

[swahtz]

Actually I'm finding that vscode/cursor is changing the formatting of C++ source files with this fvdb environment. Let me see if I can fix it

[swahtz]

I found that without changing the path to the clang-format-18 tool, we were getting source files reformatted with the wrong clang-format version. If you can apply this patch, I found this should fix that situation:

diff --git a/.vscode/settings.json b/.vscode/settings.json
index 0015bbb..f81ee57 100644
--- a/.vscode/settings.json
+++ b/.vscode/settings.json
@@ -58,7 +58,7 @@
     "json.format.keepLines": true,

     "clangd.path": "${env:CONDA_PREFIX}/envs/fvdb/bin/clangd",
-    "clangFormat.executable.linux": "${env.CONDA_PREFIX}/envs/fvdb/bin/clang-format",
+    "clangFormat.executable.linux": "${env.CONDA_PREFIX}/envs/fvdb/bin/clang-format-18",
     "cursorpyright.analysis.diagnosticSeverityOverrides": {
         "reportPrivateImportUsage": "none"
     },