Hello, so normally passing -DCMAKE_EXPORT_COMPILE_COMMANDS=YES to your CMake invocation will generate the compile_commands into the build directory automatically. You'd want to symlink it from the build directory into the project root if you're building out-of-source so that clangd and sourcekit-lsp can find it and use it as the project "root". Unfortunately, that still doesn't quite work for Swift yet due to how CMake models a Swift build. The : in the command position is effectively a more universal /usr/bin/true so things don't "crash", but it certainly isn't enough for LSP to do anything meaningful. I have a branch here that re-models Swift in CMake, and one of the things it does is hook up the emission of the compile-commands correctly so we do get LSP: Files · ewilde/swiftly-remodelling · Evan Wilde / CMake · GitLab
The branch isn't quite ready for prime-time which is why it's not in a PR yet; WMO doesn't work at all and a few other dependency edges are missing, but it is somewhat livable for little experiments (or just generating compile_commands and then using real CMake) if you want to try it out. In my early testing, it does actually have autocomplete and go to definition mostly works, which is kind of fun (though it usually jumps into the bridging header when asking for the definition of the Swift function in C++).
As per the clang version, I think that's just because someone didn't update the Clang version. It's from the swift/release/5.9 branch, which came from stable/20221013 in GitHub - apple/llvm-project: The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. This fork is used to manage Apple’s stable releases of Clang as well as support the Swift project., so the clang is about a year more recent than clang-13.