Semantic highlighting in Objective-C seems completely wrong

Development SourceKit-LSP
1

The attached Objective-C main.m file seems to get completely wrong semantic highlighting.

I tested this with a buildserver-enabled project and also with a fresh, compilation-database project + SourceKit LSP. VSCode had shown the same token types and modifiers.

Swift 6.3.3 with both Xcode and Swiftly toolchain on Linux (Swiftly) and macOS (both).

I noticed a translation of token types in the log.

Is it possible that there's a missing (reverse) mapping?

Interpreting the SourceKit token type values as clangd values would show a much more reasonable highlighting (e.g. "class" instead of "parameter" for mapping "8: 2"). If that's true, then it would indicate a missing mapping of types received by clangd to the SourceKit LSP types, as far as I understand.

Thanks!

#import <Foundation/Foundation.h>

@interface MyClass: NSObject // <- "MyClass" is "parameter", "NSObject" is "parameter"

@end

@implementation MyClass // <- "MyClass" is "parameter"

@end

int main(int argc, char* argv[]) { // <- "main" is "type", "argc" is "variable"

}

Legend emitted by SourceKit LSP via dynamic registration

          "legend": {
            "tokenModifiers": [
              "declaration",
              "definition",
              "deprecated",
              "deduced",
              "readonly",
              "static",
              "abstract",
              "virtual",
              "dependentName",
              "defaultLibrary",
              "usedAsMutableReference",
              "usedAsMutablePointer",
              "constructorOrDestructor",
              "userDefined",
              "functionScope",
              "classScope",
              "fileScope",
              "globalScope"
            ],
            "tokenTypes": [
              "variable",
              "variable",
              "parameter",
              "function",
              "method",
              "function",
              "property",
              "variable",
              "class",
              "interface",
              "enum",
              "enumMember",
              "type",
              "type",
              "unknown",
              "namespace",
              "typeParameter",
              "concept",
              "type",
              "macro",
              "modifier",
              "operator",
              "bracket",
              "label",
              "comment"
            ]
          }

clangd -> SourceKit translations from the Log:

2026-07-30 14:04:28.894227+0200 0x3af211   Info        0x0                  55926  0    sourcekit-lsp: [org.swift.sourcekit-lsp:notification-2] clangd token type translations (1/1)
0: 8
1: 8
2: 7
3: 12
4: 13
5: 12
6: 9
7: 8
8: 2
9: 4
10: 3
11: 10
12: 1
13: 1
14: 26
15: 0
16: 6
17: 25
18: 1
19: 14
20: 16
22: 23
23: 24
24: 17

2026-07-30 14:04:28.894242+0200 0x3af211   Info        0x0                  55926  0    sourcekit-lsp: [org.swift.sourcekit-lsp:notification-2] clangd token modifier translations (1/1)
2: 4
3: 10
4: 2
5: 3
6: 5
7: 11
8: 12
10: 13
11: 14
12: 15
13: 16
14: 17
15: 18
16: 19
17: 20
2

Does sourcekit-lsp highlight Objective-C code as if it were Swift code?

3

I'm not sure how I could find out if it does.

But I don't think so, I see diagnostics, hover data, etc. which are expected for Objective-C code and which seem valid.

1 Like
4

At least according to the sources, there should be a translation of clangd token types to LSP token types. I'm not sure what's wrong (clangd itself, the translation, or something else), but I haven't seen expected highlighting for Objective-C sources yet.

5

This sounds like it might be SourceKit-LSP overrides syntax highlighting provided by clangd · Issue #2643 · swiftlang/sourcekit-lsp · GitHub, which was fixed in Always advertise the SourceKit-LSP semantic tokens legend by Steffeeen · Pull Request #2712 · swiftlang/sourcekit-lsp · GitHub. Could you check if you’re still seeing the issue in the latest nightly main snapshot?

1 Like
6

With the latest main-snapshot (6.5) the highlighting is better, so it's seems like it's the same bug.

I couldn't see that on GitHub, but would the fix also land with Swift 6.4 or only later with 6.5?

Thank you!

7

The fix is currently only in main, so it won’t be part of the 6.4 release.

1 Like