On some editors (namely VSCode) documentLinks are rendered with an
underline, which might be distracting to see. This patch adds a flag to
disable such request, as it's used only for includes, and the open include
feature can be already fulfilled by the definition request
Details
- Reviewers
sammccall
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Can you apply the clang-format patch suggested by the pre-merge bot. Alternatively, if you have a recent version of clang-format and the appropriate git-hooks you should be able to run git clang-format for the same effect.
Seems fair enough to do something about this, though it's a bit sad we're doing it just because VSCode has bad UI.
A couple of open design questions:
- In the future it may make sense to have other documentLinks too. (e.g. imagine a comment Configures the Frobnicator - we should linkify Frobnicator to point to a class, once documentLink supports target ranges). So we should decide if this feature is "disable documentLink" or "don't include included headers in documentLink". This affects e.g. naming of the flag, which is awkward to change later.
- Do we really want to add command-line flags for this or does it rather belong as a config option? (In which case we'd want to change the behavior of the method, not turn the method itself on/off, to allow the config option to vary across files in the usual way).
clang-tools-extra/clangd/ClangdLSPServer.cpp | ||
---|---|---|
639 | this is worth a comment: Currently we only provide documentLink for #included headers. If that's turned off, let clients avoid sending the request altogether. | |
1513 | It seems simpler for debugging and tests to leave the method bound regardless, and only associate the *capability* with the option. This is what we usually do, though foldingRange wasn't done this way for some reason. (Maybe because we know it's *crashy* so we're being extra cautious). In any case, no need for it in this case. | |
clang-tools-extra/clangd/ClangdLSPServer.h | ||
55 | this belongs below in the list of per-feature options. | |
clang-tools-extra/clangd/test/xrefs.test | ||
4 | Having tests depend on external headers is a bit of a pain downstream - it means they need to run in an environment where the headers are available. We do this by necessity in document-link.test - maybe we should move this test here? |
In the future it may make sense to have other documentLinks too. (e.g. imagine a comment Configures the Frobnicator - we should linkify Frobnicator to point to a class, once documentLink supports target ranges). So we should decide if this feature is "disable documentLink" or "don't include included headers in documentLink". This affects e.g. naming of the flag, which is awkward to change later.
I think it's already like that, in that specific case, and it uses goToDefinition instead: if I ctrl+click on a variable/class/function name in a comment i can actually go to the definition, if I am not wrong.
As for the naming of the option, maybe the title of the patch is not too accurate, however from the option description it's quite clear that it's only related to include files, so any additional feature using documentLinks should be easy to add while keeping this option too.
Do we really want to add command-line flags for this or does it rather belong as a config option? (In which case we'd want to change the behavior of the method, not turn the method itself on/off, to allow the config option to vary across files in the usual way).
In my opinion (and also by looking at the already implemented options in .clangd config file) the config file seems to be related to project specific configurations (compilation flags, indexing, etc.), whereas the option that this patch implements is more related to the "editing experience", which is something one should not change very often. So I think that it might not be worth putting it in the config file.
clang-tools-extra/clangd/test/xrefs.test | ||
---|---|---|
4 | I'm moving the test, as it is related to document links it seems pertinent to put it there, if you prefer we can leave it out of course |
this belongs below in the list of per-feature options.