This allows more flexibility than --compile-commands-dir flag or ancestor-based discovery.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I believe we should log some warning at startup if user has provided --compile-commands-dir. Saying that "CDB search customizations through config is disabled". (only emitting the warning when we hit a config with CDB search customization would be nicer, but plumbing and making ConfigCompiler aware of such things sounds terrifying :/)
mostly LG, didn't get a change to look at the tests yet (will do so soon)
clang-tools-extra/clangd/ConfigCompile.cpp | ||
---|---|---|
269 | i hope no one tries to put their CDBs in a directory named Ancestors/None :))) (it is definitely better than breaking any project with a top-level directory named Ancestors/None) | |
280 | +1 i think it should. | |
clang-tools-extra/clangd/GlobalCompilationDatabase.cpp | ||
617 | missing a Child = &Info; ? | |
651 | nit: DirValues[I]->State = DirCaches[I] == ThisCache ? DirInfo::TargetCDB : DirInfo::Unknown;, to reduce branching. | |
681 | s/P.getInt()/1 as we'll bail out otherwise. | |
718 | s/Recursive/Recursive=/ |
clang-tools-extra/clangd/unittests/ConfigCompileTests.cpp | ||
---|---|---|
142 | maybe also try with an absolute path in CompilationDatabase ? |
So I considered this, but it depends on what we want the eventual interaction of flags and config to be.
A) if we're going to eliminate any flags that overlap with config, the message should say the flag is deprecated
B) if config is going to override flags, the message should say that the flag overrides config for now but this will change
C) if flags are going to override config, I don't think we should log a message when any such flag is used...
Personally I lean toward C and so don't want to log. I realize that there's legacy users of this flag that may not know the alternative, but equally there are future users of this flag that will be not-helped by such a log message.
clang-tools-extra/clangd/ConfigCompile.cpp | ||
---|---|---|
269 | Haha, yes... you could always write ./Ancestors then, I suppose. (Obviously we can work around this with a more complicated structure... but I'm not sure it's a good trade) | |
280 | Right... the reason I didn't make the change in this patch is that it affected MountPoint of indexes, and there were tests of that, and code using starts_with in a way that suggested it might be important. So we should clean this up somehow, but I didn't want to bite it off here. | |
clang-tools-extra/clangd/GlobalCompilationDatabase.cpp | ||
617 | Nice catch, I guess I didn't have enough levels in my tests... | |
651 | This seems less clear to me, the branch is fairly predictable, and this function is pretty cold - I'd rather keep init as is for readability. |
thanks, lgtm!
clang-tools-extra/clangd/ConfigCompile.cpp | ||
---|---|---|
280 | SG. As a note to future self, I don't remember the tests but in theory the startswith should be fine with and without the trailing slash. |
i hope no one tries to put their CDBs in a directory named Ancestors/None :)))
(it is definitely better than breaking any project with a top-level directory named Ancestors/None)