New files opened in helix editor lack symbols from the same package

[dmbfm]

Swift version

swift-driver version: 1.127.14.1 Apple Swift version 6.2 (swiftlang-6.2.0.19.9 clang-1700.3.19.1) Target: arm64-apple-macosx26.0

Platform

macOS 26

Editor

Helix

Description

When I create a new file in helix (e.g., by using :o <filepath>), although code completion and diagnostics keep working on this file, they lack any of the symbols of the module the file is placed in. Only after restarting the server via :LspRestart do the symbols appear correctly.

From what I could gather in the logs, source-kit receives the textDocument/didOpen notification from helix, but it does not seem to recognize the workspace of the file:

Build settings for file:///Users/dfortes/Developer/dump/SomeProject/Sources/SomeProject/Other.swift (1/1)
Compiler Arguments:
-sdk
/Applications/Xcode-26.0.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.0.sdk
/Users/dfortes/Developer/dump/SomeProject/Sources/SomeProject/Other.swift

Working directory:
<nil>

and

Producing syntactic diagnostics from the built-in swift-syntax because we have fallback build settings)

Steps to Reproduce

Create a new project:

mkdir SomeProject
cd SomeProject
swift package init

Open the helix editor:

hx Sources/SomeProject/SomeProject.swift

Set the source code to something like:

struct Model {
	var x: Int
}

Open a new file by using the command: :o Sources/SomeProject/OtherFile.swift; code completion will still work for libraries like Foundation, but the Model struct won't be found.

Logging

sourcekit-lsp-diagnose-2025-10-06T15-23-13-03-00.zip

[ahoppen]

Does Helix create the file on disk when you create it using :o <filepath>? To me it appears like the file doesn’t exist on disk when you create it Helix (and thus it’s not part of the Swift package, which is why we don’t get build settings for it). The first workspace/didChangeWatchedFiles notification that we get about Other.swift has "type" : 2, ie. FileChangeType::Changed and we don’t get a FileChangeType::Created for the file. This would constitute a bug in the editor’s LSP implementation if it doesn’t inform the LSP server about the file’s creation.

[dmbfm]

That is true, the file only exists after saving. But this issue happens even if I, for instance, create the file using touch and then open it inside helix.

I do believe helix never sends a FileChangeType::Created, it only emits FileChangeType::Changed:

https://github.com/helix-editor/helix/blob/c599e4e7ee5222692c6c2a2de1edc1994afb39ee/helix-lsp/src/file_event.rs#L116-L122

Searching helix' codebase this is the only place where FileChangeType is ever used. Does this mean that the issue is caused by the Helix LSP implementation?

[ahoppen]

Yes, if Helix is only sending Changed events, then that’s a bug in Helix’s LSP implementation. We definitely don’t want to reload the package every time a file is modified.

As a workaround, you can also touch (or do a simple edit) Package.swift instead of restarting SourceKit-LSP. Modifying the package manifest will also reload the package.

[dmbfm]

Thanks for the tip! For context, it seems there is a PR on helix to fix this: helix-editor/helix#14544

[bnbarham]

While I agree that Helix's LSP implementation should be updated here, I do think it's reasonable that we should provide better fallback settings for new files regardless. Otherwise there's a bit of a delay while the build server is recomputing everything.

We currently have

sourcekit-lsp/Sources/BuildServerIntegration/SwiftPMBuildServer.swift

Lines 662 to 683 in b8da832

	if !swiftPMTarget.sources.lazy.map({ DocumentURI($0.sourceFile) }).contains(request.textDocument.uri),
	let substituteFile = swiftPMTarget.sources.map(\.sourceFile).sorted(by: { $0.description < $1.description }).first
	{
	logger.info("Getting compiler arguments for \(url) using substitute file \(substituteFile)")
	// If `url` is not part of the target's source, it's most likely a header file. Fake compiler arguments for it
	// from a substitute file within the target.
	// Even if the file is not a header, this should give reasonable results: Say, there was a new `.cpp` file in a
	// target and for some reason the `SwiftPMBuildServer` doesn’t know about it. Then we would infer the target based
	// on the file's location on disk and generate compiler arguments for it by picking a source file in that target,
	// getting its compiler arguments and then patching up the compiler arguments by replacing the substitute file
	// with the `.cpp` file.
	let buildSettings = FileBuildSettings(
	compilerArguments: try await compilerArguments(for: DocumentURI(substituteFile), in: swiftPMTarget),
	workingDirectory: try projectRoot.filePath,
	language: request.language
	).patching(newFile: DocumentURI(try path.asURL.realpath), originalFile: DocumentURI(substituteFile))
	return TextDocumentSourceKitOptionsResponse(
	compilerArguments: buildSettings.compilerArguments,
	workingDirectory: buildSettings.workingDirectory
	)
	}

for SwiftPM but:

1. We never get here in this case, as the file isn't a part of any target we know about and we then only provide fallback settings
2. This isn't quite what we'd want for Swift anyway - we should be adding the file in that case

I'm going to re-open this for the purposes of providing fallback settings based on eg. a sibling file. It should be in BuildServerManager where we would then also make sure to set the fallback settings flag. Note that other files in the same module will still not see additions in the new file until the build server is up to date.