By exposing a callback that can guard code publishing results of
'onMainAST' callback in the same manner we guard diagnostics.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
I think this is the right design. As mentioned offline, I think we can now move the onDiagnostics call out from TUScheduler into ClangdServer (and remove onDiagnostics from the callbacks interface).
This is a better layer because the diagnostics callback model is really about how LSP treats diagnostics, and TUScheduler shouldn't have to care much (maybe one day this will even live in ClangdLSPServer).
| clang-tools-extra/clangd/TUScheduler.h | ||
|---|---|---|
| 105 ↗ | (On Diff #210787) | I'd consider having the typedef be the full using PublishFn = llvm::function_ref<void(llvm::function_ref<void()>)> That way the signature of onMainAST is simpler, and realistically people are going to understand how to call Publish by example. |
| 118 ↗ | (On Diff #210787) | I think we need to explain the API before apologising for it (explaining why it's this shape etc). And I think this is weird enough that an example would help. Something like: When information about the file (diagnostics, syntax highlighting) is published to clients,
this should be wrapped in Publish, e.g.
void onMainAST(...) {
Highlights = computeHighlights();
Publish([&] { notifyHighlights(Path, Highlights); });
}
This guarantees that clients will see results in the correct sequence if the file is concurrently closed
and/or reopened. (The lambda passed to Publish() may never run in this case). |
- Use the same mechanism for diagnostics
- Change typedef to function<void(function<void()>)>
- Update a comment
- s/PublishResults/PublishFn
- Reformat
Awesome, I think this is in better shape than before highlighting was added.
| clang-tools-extra/clangd/TUScheduler.h | ||
|---|---|---|
| 102 ↗ | (On Diff #210807) | uber-nit: newline before this, as currently it's grouped with onPreambleAST rather than onMainAST |