So that clang can infer target from argv[0] of command line invocation
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 33860 Build 33859: arc lint + arc unit
Event Timeline
clang-tools-extra/clangd/GlobalCompilationDatabase.cpp | ||
---|---|---|
36 | Do we actually need this if we provide a proper Argv[0] to the driver? | |
clang-tools-extra/clangd/test/target_info.test | ||
2 | Could you add a short human-readable description of the test setup here? Try to mock 'compile_commnands.json' for fuchsia-based builds and check the corresponding target flags are being passed into clang. | |
9 | This is added unconditionally on all platforms, right? |
clang-tools-extra/clangd/GlobalCompilationDatabase.cpp | ||
---|---|---|
36 | unfortunately yes. because if the "-target" is missing, driver tries to deduce it from the "running binary" which is "clangd" in our case. | |
clang-tools-extra/clangd/test/target_info.test | ||
9 | no it is not, this checks whether we have a drive letter in the file uri ("[A-Z]:") and adds the slash in that case. |
clang-tools-extra/clangd/GlobalCompilationDatabase.cpp | ||
---|---|---|
36 | I wonder if it would sense to change this? Where does this code live? That's exactly what argv[0] is for in compile_commands.json. Fixing that at the driver level would "fix" all libclang- and libtooling-based binaries, like clang-tidy, etc. |
clang-tools-extra/clangd/test/target_info.test | ||
---|---|---|
9 | Ah, ok, LGTM. Missed that. |
- Move target name deduction into Driver
clang-tools-extra/clangd/GlobalCompilationDatabase.cpp | ||
---|---|---|
36 | ah sorry, I've mixed that one actually. the behavior is: if the "-target" is missing, we always use the default target(depends on the host). even though ClangExecutable is available in the Driver and set correctly to argv[0]. adding this to rather driver side, looks like nothing is broken. |
Nice, thanks! The clangd parts obviously LGTM, but let's be more conservative with the driver bits (see the relevant comment)
clang-tools-extra/clangd/test/target_info.test | ||
---|---|---|
29 | This is a marvellous hack! | |
clang/lib/Driver/Driver.cpp | ||
1055 ↗ | (On Diff #204484) | I strongly think the driver is the right place to do this, but we have to watch out for breakages coming from this. The drivers code has way more uses than clangd code, so we should expect that people rely on all kinds of things there. Could you separate the driver pieces into a separate change and add driver tests for them? To make it more focused and easier to revert in case of breakages. |
Sorry about the confusion, I can now see why the original version of the patch was actually simpler.
I was put off by the fact that we override by adding command-line arguments instead of passing things around in the code, but it appears that's actually simpler than adding yet another mechanism to override target tripple in the driver.
The only suggestion from me would be maybe try moving this to a layer that would also make also benefit other compilation-db-based things like clang-tidy, etc?
Any ideas on how to do this? Would this potentially break anything?
I've made it a wrapper for JSON-based compilation database(as inferring cdb does), there were no breakages in tests.
Hopefully all clang-based tools can benefit from it by linking in target infos and enabling them at startup.
- Introduce a new wrapper CDB that adds target and mode info to returned compile commands
Thanks, this looks very good!
Leaving a few nitpicky comments, but nothing important really.
Two more general NITs:
- could we update the title and description of this revision to mirror that it focuses on code in tooling rather than in clangd?
- maybe land the clangd parts into a separate change for nicer VCS history?
clang/include/clang/Tooling/CompilationDatabase.h | ||
---|---|---|
220 ↗ | (On Diff #206193) | NIT: in the spirit of a previous name, we could shorten the name inferTargetAndDriverMode(…) |
clang/lib/Tooling/CMakeLists.txt | ||
25 ↗ | (On Diff #206193) | NIT: GuessTargetAndDriverModeCompilationDatabase would align better with the names of other files that define compilation databases. It looks a little long, though, maybe there's a better word to capture TargetAndMode |
clang/lib/Tooling/TargetAndModeAdderDatabase.cpp | ||
39 ↗ | (On Diff #206193) | NIT: maybe accept by value to simplify the code? |
LGTM
clang-tools-extra/clangd/GlobalCompilationDatabase.cpp | ||
---|---|---|
14 | looks like accidental leftover from a previous revision. Remove? |
looks like accidental leftover from a previous revision. Remove?