sammccall added a comment. Got here trying to understand how D60126 <https://reviews.llvm.org/D60126> works.
It seems there's two fairly independent changes here: - the one described, allow actions to run without a preamble - defer the blocking getCompileCommand() call until we're building the preamble Certainly they interact to make zero-latency code completion work, but is it possible to pull the latter out of this patch? There are other approaches to the second part (e.g. giving TUScheduler a reference to the global CDB) that might be cleaner. I don't think it needs to block D60126 <https://reviews.llvm.org/D60126>. ================ Comment at: clangd/TUScheduler.h:204 + Callback<InputsAndPreamble> Action, + bool AllowFallback = false); ---------------- I think this isn't orthogonal to `PreambleConsistency`. When would we use AllowFallback = true but PreambleConsistency = Consistent? Two possible options: - adding a new `StaleOrAbsent` option to PreambleConsistency - changing `Stale` to these new semantics, as codeComplete is the only caller The problem with the latter is we can't put it behind a flag. Repository: rCTE Clang Tools Extra CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59811/new/ https://reviews.llvm.org/D59811 _______________________________________________ cfe-commits mailing list firstname.lastname@example.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits