nridge added inline comments.
================
Comment at: clang-tools-extra/clangd/GlobalCompilationDatabase.h:165
+// process a file (possibly different from the one in the command).
+class CompileCommandsAdjuster {
+public:
----------------
sammccall wrote:
> I have a couple of concerns with this interface:
> - we seem to be stretching to cover {mangler, querydriver} with one
> interface, but there's no particular reason to - we never use it
> polymorphically.
> - the contract is very vague. If it's just "mutate flags" then some sort of
> generic `function<void(CompileCommand&)>` seems sufficient
> - `File` feels out-of-place - it's purely an input for the mangler. If
> query-driver needs an extra input, will we add that too?
> - either `CompileCommand` or filename+argv seems reasonable, providing
> CompileCommand+argv is confusing.
> - the name is hard to distinguish from tooling::ArgumentsAdjuster (which is
> a bad interface)
>
> The immediate problem being solved is the type of
> CommandMangler::SystemIncludeExtractor, right?
> Can that just be `unique_function<void(vector<string>&, StringRef)>` or so?
> Possibly behind `using SystemIncludeExtractor = ...`.
It's more that `QueryDriverDatabase`
[uses](https://searchfox.org/llvm/rev/f213128b292da85f68eeebbb68cba1541e1c39e2/clang-tools-extra/clangd/QueryDriverDatabase.cpp#354)
the `Directory` field of `tooling::CompileCommand` in addition to the
arguments.
We could add the directory as another argument to the function, but at that
point why not group the arguments into `tooling::CompileCommand` which is more
semantically meaningful?
As for polymorphism vs. `unique_function`, I don't feel strongly about that,
happy to change that up. (I do find `function` more annoying to debug because
`step into` at a call site in the debugger steps into some hard-to-read library
code, but that's probably better solved at the debugger tooling level.)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D133756/new/
https://reviews.llvm.org/D133756
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
