phosek added a comment. One more thing, do you think it's reasonable to use `llvm::sys::findProgramByName(Args[0])`instead of `Args[0]` when creating the driver instance? One of the failure modes I ran into is the case where the generated compilation database would contain just the executable name, e.g. `clang++`. If you invoke that command, everything works as expected because driver resolves the binary to a full path <https://github.com/llvm/llvm-project/blob/master/clang/tools/driver/driver.cpp#L58>, but when used with `clangd`, it'll fail because that resolution will never happen, the `Dir`/`InstalledDir` will be an empty path and attempt to resolve C++ library headers will end up with `/../include/c++/v1` which is invalid.
Alternative would be to make the compilation database specification even more strict and require that the compiler command is not only the first argument, but it's also a (full or relative) path to the compiler executable. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D63092/new/ https://reviews.llvm.org/D63092 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits