sammccall added a comment.

Got here trying to understand how D60126 <> 

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 <>.

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.

  rCTE Clang Tools Extra


cfe-commits mailing list

Reply via email to