Open rchl opened 6 days ago
As discussed at https://clangd.llvm.org/troubleshooting.html#gathering-logs, this can be done by adding --log=verbose
to "clangd.arguments"
.
Thanks, it works.
That said, the vscode language client libraries support a setting like clangd.trace.server
out of the box. The only thing that makes it problematic in this case is that clang already exposes a clangd.trace
setting for different purpose which causes a conflict.
So I suppose you wouldn't want to rename the existing setting to make the standard one work? If not then feel free to close this issue.
the vscode language client libraries support a setting like
clangd.trace.server
out of the box.
Do you know how this works at the protocol level?
I'm not sure I understand the question but since the whole protocol communication goes through the language client, it's able to post this data to the output panel.
The log would look something like this (it's from a different server):
[Trace - 22:06:19] Sending request 'textDocument/codeAction - (31)'.
Params: {
"textDocument": {
"uri": "file:///usr/local/workspace/lsp/lsp-log-parser/components/app-bar.vue"
},
"range": {
"start": {
"line": 145,
"character": 35
},
"end": {
"line": 145,
"character": 35
}
},
"context": {
"diagnostics": [],
"triggerKind": 2
}
}
[Trace - 22:06:19] Received response 'textDocument/codeAction - (31)' in 4ms.
Result: []
It's arguably more readable that one-liners from clangd.
Here is the change that would be needed - https://github.com/rchl/vscode-clangd/commit/9464e4ed23e83d89db0c7b80467e5070f10cf909
The language server ID is assigned explicitly since otherwise it's inferred from name which doesn't play nice with settings.
Of course this change tramples the original clangd.trace
setting so if supporting this new option is desired then there would need to be some breaking change done to solve this issue.
EDIT: Also... enabling clangd.trace.server
results in language client sending a $/setTrace
notification to the server:
[Trace - 21:48:56] Sending notification '$/setTrace'.
Params: {
"value": "verbose"
}
so the server can toggle some logic based on that (like the logging associated with the current clangd.trace
setting, for example).
Ok, I see, this logging is implemented entirely in the client.
It's arguably more readable that one-liners from clangd.
Note that clangd will also pretty-print the protocol traffic if --pretty
is added to "clangd.arguments"
.
Also, the server logs include additional information beyond the protocol traffic, so this client-side logging couldn't replace them altogether. (But we could still provide the client-side logging as well, for discoverability purposes.)
Here is the change that would be needed - rchl@9464e4e
Thanks, this is helpful.
Of course this change tramples the original
clangd.trace
setting so if supporting this new option is desired then there would need to be some breaking change done to solve this issue.
@hokein, any thoughts on whether it's OK to rename the existing clangd.trace
setting? Technically it would be a breaking change for users who use the existing setting, but the breakage would be easy to resolve by switching to the new name.
Most LSP extensions expose a setting to configure the verbosity of the LSP output in the extension output panel. This extension doesn't seem to support that. There is
clangd.trace
option but that is not what I'm looking for (it's a lower level communication).Most third party of built-in extensions expose a setting like
"ruff.trace.server": "verbose",
"json.trace.server": "verbose",` etc.