lgtm

• use sync runAddDocument in test

• address comments

• Only return compile command (instead of FileInputs) from AST worker.

• address comments

• Add missing comment to TUScheduler.h

• address review comments

• Add test comment.

in case you missed this patch :)

lgtm

• address comments

• address review comments

Feel free to land this. I'll rebase D60126 on this when it's in.

lgtm

Thanks for the review!

• minor cleanup

• address review comments

lg!

• address review comments

• Fix unit test

Oops, forgot to update tests...

• split out the compile command change.

In D59376#1454834, @ymandel wrote:

In D59376#1454768, @ilya-biryukov wrote:

Per @ioeric's suggestion: why not move the helper into Tooling/Refactoring/ExtendedRange.h?
If it's in ToolingRefactoring, both stencil and transformer can access it.

For external users, a dependency on either ToolingCore or ToolingRefactoring should be fine, since they're fine with a dependency on Tooling already.

This sounds perfect. Can I do the same for the future additions -- small, focused libraries for each group of functions? I just want to be sure that we don't regret the name "ExtendedRange" when I need to add the next batch.

• Improved test.

• Rebase

• address review comments.

In D59811#1445701, @ilya-biryukov wrote:

I think this option should be configurable (and off by default) for the transition period. A few reasons to do so:

• Before we have an actual implementation of fallback completions, the current behavior (waiting for the first preamble) actually seems like a better experience than returning empty results.
• Some clients do this kind of fallback on their own (e.g. VSCode), so until we can provide actually semantically interesting results (anything more than identifier-based really, e.g. keyword completions) we would be better off keeping it off.
• We can still test it if it's off by flipping the corresponding flag in the test code.
• Would make rollout easier (clients can flip the flag back and forth and make sure it does not break stuff for them)

lgtm

Neat!

should we update YAML?

I don't follow why this can over-count, FileIndex keeps only one RefSlab per each file, so we can't over-count? Did you mean it will be more than #TUs ?

Yes. This is how Symbol::References is described in its documentation. If we want to change/expand the semantic, we need to make it clear in the documentation as well.

I'm not sure if FileIndex is the correct layer to make decision about how References is calculated. Currently, we have two use cases in clangd 1) one slab per TU and 2) one slab per file. It seems to me that we would want different strategies for the two use cases, so it might make sense to make this configurable in FileIndex. And in one case, we have References ~= # of TUs, and in the other case, we would have References ~= # of files. This can over-count References in the second case. It might be fine as an approximation (if there is no better solution), but we should definitely document it (e.g. in BackgroundIndex).

(The result looks great)