Details
- Reviewers
hokein kadircet ilya-biryukov sammccall
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 41353 Build 41555: arc lint + arc unit
Event Timeline
This is not for review yet, I'm just posting it to illustrate the client side of D67536.
clang-tools-extra/clangd/clients/clangd-vscode/src/semantic-highlighting.ts | ||
---|---|---|
210 | I'm open to suggestions for how we could avoid harcoding these colors. VSCode themes do not seem to include colors for "meta.disabled" or any similar scope that would fit this role. Perhaps we can allow the user to define the colors in clangd-specifier setting names, e.g. clangd.inactiveHighlightColor.light? |
sorry for the looong delay, I was OOO for a few weeks before.
The patch looks fine, my concern is that how do we support this line extension when LSP provides a standard implementation -- there is some significant progress about semantic highlighting on VSCode, VSCode now provides an experimental semantic token API, but no LSP binding yet (is not far away I think). When it is ready, we'd like to switch to that and get rid of our own implementation. Looking at the API there, it seems like we could make the line-style scope name meta.disable clangd specific, and define our own style.
clang-tools-extra/clangd/clients/clangd-vscode/src/semantic-highlighting.ts | ||
---|---|---|
293 | another solution that requires minimal changes (but more hacky) is that, since clangd emits a meta.disabled token with line-set-only range, we could inject the inactiveCodeDecorationType to the meta.disabled slot of Highlighter::decorationTypes, and everything should work. |
Agreed.
(One potential issue is that vscode themes don't support background styling. However, that issue has been getting a lot of attention, hopefully it too will be fixed soon.)
I do think there's value in landing this patch in the interim.
Looking at the API there, it seems like we could make the line-style scope name meta.disable clangd specific, and define our own style.
Do you mean naming the scope something like clangd.meta.disable to make it clear it's a clangd extension?
(In that case, we might as well make it something more descriptive, like clangd.preprocessor.inactive. meta doesn't convey much information.)
Unit tests: fail. 62144 tests passed, 5 failed and 811 were skipped.
failed: libc++.std/language_support/cmp/cmp_partialord/partialord.pass.cpp failed: libc++.std/language_support/cmp/cmp_strongeq/cmp.strongeq.pass.cpp failed: libc++.std/language_support/cmp/cmp_strongord/strongord.pass.cpp failed: libc++.std/language_support/cmp/cmp_weakeq/cmp.weakeq.pass.cpp failed: libc++.std/language_support/cmp/cmp_weakord/weakord.pass.cpp
clang-tidy: fail. clang-tidy found 2 errors and 0 warnings. 0 of them are added as review comments below (why?).
clang-format: fail. Please format your changes with clang-format by running git-clang-format HEAD^ or applying this patch.
Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml
Pre-merge checks is in beta. Report issue. Please join beta or enable it for your project.
Do you mean naming the scope something like clangd.meta.disable to make it clear it's a clangd extension?
(In that case, we might as well make it something more descriptive, like clangd.preprocessor.inactive. meta doesn't convey much information.)
yes, this was my suggestion.
clang-tools-extra/clangd/clients/clangd-vscode/src/semantic-highlighting.ts | ||
---|---|---|
198 | hmm, looks like clangd omits the InactiveCode token. I'd suggest we send it like other tokens, that will simplify the patch, we don't need the inactiveDecorationIndex and isInactive, I think it also helps when we migrate to the official implementation. WDYT? |
clang-tools-extra/clangd/clients/clangd-vscode/src/semantic-highlighting.ts | ||
---|---|---|
198 | This was discussed fairly extensively in the server-side review (https://reviews.llvm.org/D67536). In the end, we decided to go with this approach of having a separate field in the protocol for inactive lines, for a variety of reasons including the one discussed in https://reviews.llvm.org/D67536#inline-616346 |
hmm, looks like clangd omits the InactiveCode token.
I'd suggest we send it like other tokens, that will simplify the patch, we don't need the inactiveDecorationIndex and isInactive, I think it also helps when we migrate to the official implementation. WDYT?