- DynamicIndex doesn't implement ParsingCallbacks, to make its role clearer. ParsingCallbacks is a separate object owned by the receiving TUScheduler. (I tried to get rid of the "index-like-object that doesn't implement index" but it was too messy).
- Clarified(?) docs around DynamicIndex - fewer details up front, more details inside.
- Exposed dynamic index from ClangdServer for memory monitoring and more direct testing of its contents (actual tests not added here, wanted to get this out for review)
- Removed a redundant and sligthly confusing filename param in a callback
Details
Diff Detail
- Repository
- rCTE Clang Tools Extra
- Build Status
Buildable 21881 Build 21881: arc lint + arc unit
Event Timeline
Thanks for the cleanups, mostly NITs from my side.
clangd/ClangdServer.cpp | ||
---|---|---|
81 | Maybe return const SymbolIndex& and keep the method const? | |
101 | Maybe simplify to make_unique<CB>(this)? This should work, right? | |
122 | I thought it was not true, but now I notice we actually don't index those symbols. | |
152 | Any reason to prefer nullptr over the no-op callbacks? Not opposed to doing it either way, though. | |
clangd/ClangdServer.h | ||
195 | Maybe make it const? | |
clangd/TUScheduler.cpp | ||
632 | Why not ParsingCallbacks* or ParsingCallbacks&? This restricts the lifetime of the passed values. |
clangd/ClangdServer.cpp | ||
---|---|---|
122 | isExpansionInMainFile() (having this buried so deep hurts readability and probably performance). But I think this would be the behavior we want for code complete, to keep the indexes tiny and incremental updates fast? | |
152 | Basically I prefer the old behavior here (when it was std::function). We don't have the std::function copyability stuff which is a mixed bag but nice for cases like this. But passing the reference from TUScheduler to its ASTWorkers is internal enough that it doesn't bother me, WDYT?
Note that the check is actually in the constructor, supporting nullptr is just for brevity (particularly in tests). |
Address review comments, add missing dynamicIndex() implementation.
clangd/TUScheduler.cpp | ||
---|---|---|
632 | As noted above, this is just like std::function. |
LGTM
clangd/ClangdServer.cpp | ||
---|---|---|
122 | I would assume the number of symbols in the main files is not very large, compared to the ones from the preamble. | |
152 |
OTOH, this gives flexibility to the callers wrt to the lifetime, i.e. they don't have to create a separate object for the callbacks if they don't want to (one example of this pattern is ClangdLSPServer inheriting DiagnosticsConsumer and ProtocolCallbacks). But happy to do it either way. | |
clangd/TUScheduler.h | ||
158 | NIT: maybe mention that this is never null in a comment? | |
unittests/clangd/TUSchedulerTests.cpp | ||
48 | NIT: maybe add a name of the parameter here for better readability (nullptr can mean many things)? |
clangd/ClangdServer.cpp | ||
---|---|---|
152 | I don't think there's any flexibility here, callers *can't* in general create an object (unless they know enough about the lifetimes to store the object appropriately). For dependencies of the callback (e.g. lambda ref captures), either way works well.
FWIW, the former seems like an antipattern that should be std::function, to me. |
clangd/ClangdServer.cpp | ||
---|---|---|
152 |
The only limitation is that their object must outlive the ClangdServer, they have flexibility in making it a separate object, a subobject of some other object, a global static object in case it does not have state. But again, not opposed to either of these approaches.
Agreed, I would also prefer for it to be an std::function or a separate class that implements the interface. To separate the implementation of different concerns (LSP managing vs handling ClangdServer responses) better.
It's hard to draw a line between "lightweight callback pattern" and a non-lightweight one, it feels like this shouldn't affect the API choices (the only clear separation I see is between one callback function vs two and more, since we have nice syntax with lambdas for single-callback case). |
Maybe make it const?