We support sending fragments in initialize and workspace/didChangeConfiguration.
Sadly no workspace/configuration yet, we'd want to send that request on
didOpen and we'd have to block on getting the answer, which is much more
invasive.
Details
- Reviewers
kadircet
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
clang-tools-extra/clangd/ClangdLSPServer.cpp | ||
---|---|---|
1220 | nit: maybe just set ReparseAllFiles in here too, and change the condition below to only return ReparseAllFiles | |
clang-tools-extra/clangd/Protocol.h | ||
494 | it feels like clients will only be using two types of keys, a "global" one for sending over (likely project-specific) user preferences and another for directory/file specific configs. The latter is likely to have the path as a key, whereas the former will likely be a special identifier. I am glad that ! comes before both / and any capital letters(letter drives). I think it is only important to have a distinction between these two types (a subset of what you describe here). Current design makes it really easy on our side, I am just afraid of confusing clients. Maybe we should just have an enum/boolean tag saying if the fragment is global or not instead of relying on the key orderings ? |
clang-tools-extra/clangd/ClangdLSPServer.cpp | ||
---|---|---|
1220 | Is the idea here that triggering spurious reparses is cheap enough? | |
clang-tools-extra/clangd/Protocol.h | ||
494 | If we go down this path, where do we draw the line? If we're encoding this file/directory use case in the protocol somehow, why wouldn't we *require* the key to be a path, and no longer require a condition to be set for that? This is like how .clangd files are handled. Then we'd have a more natural way of dealing with priority between file/dir-specific entries (actually, maybe it coincides with sort order, ha!). But this model starts to look something much closer to the workspace/configuration server->client request, which has a scope URI attached. The recommendation from LSP folks is that actual configuration flow over that endpoint, and didChangeConfiguration just be used to notify of changes. That hasn't seemed feasible for us as we imagine all the requests issues by background index, and the bother of making everything consuming config asynchronous. But:
It would help there were some clearer practical goal we were driving towards. Propagating, say, vscode extension settings live into clangd can be done this way, but it's a sledgehammer for a peanut. Maybe live-configuring *workspace* properties is an interesting thing, but I'm not sure how much value there is when .clangd exists. |
clang-tools-extra/clangd/ClangdLSPServer.cpp | ||
---|---|---|
1220 | none :( sorry i misread this and thought the code below was doing ModifiedFiles.size() != 0 (that's way the comment was a nit) OTOH, as you noted spurious reparses are cheap(still some IO and a task in the queue). We expect the usage of updating compile commands to migrate towards configs in the future, so in theory we won't be using that optimization most of the time. Even though we've got enough info to prevent spurious reparses here, we might not in the future (e.g. reparses resulting from a config change). So I would drop the optimization(the whole Old-New comparison logic) to increase readability. but definitely not something we should do now (probably ever), so feel free to ignore. |
There are lots of choices and overlapping ideas for how the protocol should look, little urgency (it isn't going to make clangd 11), and few concrete use cases to evaluate the options.
Let's table this for now and let the ideas sink in and more use cases crop up. I definitely think we should have this, probably for clangd 12, but it's worth getting right.
nit: maybe just set ReparseAllFiles in here too, and change the condition below to only return ReparseAllFiles