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

Reply via email to