sammccall marked an inline comment as done. sammccall added inline comments.
================ Comment at: clang-tools-extra/clangd/CompileCommands.cpp:187 + // FIXME: remove const_cast once unique_function is const-compatible. + for (auto &Edit : const_cast<Config &>(Config::current()).CompileFlags.Edits) + Edit(Cmd); ---------------- kadircet wrote: > what's the rationale behind applying this before any other mangling? > > I can see that the rest of the mangling happens to make sure clangd works > out-of-the-box for "more" users, so should be safe to apply as a final step. > But on the other hand, applying config after those would give the user full > control over the final command, which I believe is equally important. I'll be honest, I don't really know which is better here. The differences are subtle, and there are arguments for each. I think we should probably just pick one and be open to changing it later. My reasoning for this behavior: currently the user view of compile commands is basically "strings in compile_commands.json", and this mangling we do is best thought of as modifying the behavior of the driver. E.g. in an ideal world `-fsyntax-only` would not be a flag, we'd just use APIs that imply that behavior. In this view of the world, the user is expected to understand compile commands + tweaks but not the mangling, so placing tweaks after mangling means they can't really reason about the transformations. And it allows stripping structurally important things we inject like `fsyntax-only` which seems wrong. This argument works better for some args/manglings than others, and the way we log args cuts against it a bit too. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82606/new/ https://reviews.llvm.org/D82606 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits