Background indexing with SwiftData

jansorg · August 1, 2026, 10:58am

For Noctule (which uses SourceKit LSP), I received a bug report that SwiftData-enabled projects don't work as expected. SourceKit-LSP: SwiftData @Model macro conformance not visible in SwiftPM package test targets (false PersistentModel diagnostics) · Issue #101 · noctule-ide/noctule-swift-plugin · GitHub

The cause was that "backgroundPreparationMode: enabled" is used by default.

With "backgroundPreparationMode: build" and also "backgroundPreparationMode: noLazy" the editor (and thus SourceKit LSP) is able resolve references and no diagnostics are shown.

Should "enabled" be capable of handling SwiftData "@Model" and similar or is it expected that only the other background preparation modes handle this correctly?

Thanks!

ahoppen · August 3, 2026, 12:49pm

It absolutely should! That’s a bug in SourceKit-LSP. Could you file a bug to GitHub - swiftlang/sourcekit-lsp: Language Server Protocol implementation for Swift and C-based languages · GitHub?

sliemeobn · August 3, 2026, 1:26pm

I think it's this issue:

github.com/swiftlang/sourcekit-lsp

Lazy prepare-for-indexing produces incomplete swiftmodules when types receive macro-synthesized extension conformances

opened 01:50AM - 19 Jun 26 UTC

ktoso

### Swift version swiftlang-6.4.0.19.4 ### Platform all platforms ### Editor… VSCode ### Description When background indexing runs with the default mode, modules that contain types decorated with macros that use `@attached(extension, conformances: ...)` appear to produce swiftmodules whose conformance information is incomplete or missing. Cross-module consumers then see spurious "type does not conform to protocol" diagnostics, broken completion, and broken jump-to-definition for APIs that depend on those conformances. Switching to `backgroundPreparationMode: "noLazy"` seems to resolve the issues. Previously thought to just expose this setting https://github.com/swiftlang/vscode-swift/pull/2291 but instead we should fix the indexing. ### Steps to Reproduce `swiftlang/swift-java` editing experience is broken due to this and reproduces easily. ### Additional context swift-java's `@JavaClass` / `@JavaInterface` macros are declared as: ``` @attached(member, names: …) @attached(extension, conformances: AnyJavaObject) public macro JavaClass(_ fullClassName: String, …) ``` Their ExtensionMacro expansion emits: ``` extension <Type>: AnyJavaObject { } ``` These macros are applied to many types across many modules in the project, and downstream modules use those types where an AnyJavaObject conformance is required. With `backgroundPreparationMode: "enabled"` (default), opening the project in VS Code with background indexing enabled produces sporadic but consistent failures (false errors, missing completion, broken jump-to-def) on code that should bevalid. With `backgroundPreparationMode: "noLazy"`, everything works correctly. The workaround currently committed to swift-java is .sourcekit-lsp/config.json: `{"backgroundPreparationMode": "noLazy"}` ### Steps to reproduce 1. `git clone https://github.com/swiftlang/swift-java && cd swift-java` 2. `rm .sourcekit-lsp/config.json` to remove the workaround setting the noLazy mode 3. Open in VS Code with the Swift extension and background indexing enabled 4. Open files that import modules containing `@JavaClass` / `@JavaInterface` types, any file containing them diagnostics / broken IDE features on uses of those types ### Logging _No response_

@ktoso is on it:

github.com/swiftlang/swift

Lazy typechecking mode must still visit and expand attached macros

opened 05:54AM - 19 Jun 26 UTC

ktoso

type checker types macro expansions

### Description Because otherwise we may be missing conformances, which then le…ads to false errors in IDEs such as VSCode since sourcekit-lsp uses the lazy typechecking mode. See https://github.com/swiftlang/sourcekit-lsp/issues/2696 for detailed writeup how it manifested in swift-java. The real place for the fix is in Swift itself though. ### Reproduction ```swift ``` ### Expected behavior Lazy typechecking must contain synthesized conformances ### Environment swiftlang-6.4.0.19.4 ### Additional information _No response_

jansorg · August 3, 2026, 5:27pm

Thank you for the reference! It looks like it's the same, so I won't create a new issue.

ktoso · August 3, 2026, 9:57pm

Thanks for the ping, I've been asked to redesign the solution PR I had there. @hamishknight had some ideas there AFAIR.

I suspect lots of people are hitting this issue so I'll plan to get back to poking at it sometime soon.