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
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to