I've been working on a BSP to integrate with the LSP and noticed a strange ambiguity, specifically whether to include the compiler itself as the first argument in TextDocumentSourceKitOptionsResponse.compilerArguments.
In my BSP currently, I follow the clang compile DB format, so I do include it. This results in SourceKitService errors like these:
[1:getBufferStamp:15619: 1.0330] failed to stat file: <working-dir>/swiftc (No such file or directory)|
[1:fileContentsForFilesInCompilerInvocation:15619: 1.0330] failed getting file contents for <working-dir>/swiftc: error opening input file '<working-dir>/swiftc' (No such file or directory)|
So clearly something's trying to interpret the compiler relative to the working dir, which is almost always incorrect.
Looking at the built in build system in the LSP, I see that FixedCompilationDatabaseBuildSystem does include it (without absolute path, like my implementation):
return TextDocumentSourceKitOptionsResponse(
compilerArguments: [compilerName] + compilerArgs + [request.textDocument.uri.pseudoPath],
workingDirectory: try? configPath.deletingLastPathComponent().filePath
)
and both JSONCompilationDatabaseBuildSystem and SwiftPMBuildSystem drop it:
return TextDocumentSourceKitOptionsResponse(
compilerArguments: Array(command.commandLine.dropFirst()),
workingDirectory: command.directory
)
func compileArguments(for fileURL: URL) throws -> [String] {
// Note: we ignore the `fileURL` here as the expectation is that we get a command line for the entire target
// in case of Swift.
let commandLine = try description.emitCommandLine(scanInvocation: false, writeOutputFileMap: false)
// First element on the command line is the compiler itself, not an argument.
return Array(commandLine.dropFirst())
}
Some clarity would be appreciated here. It's unclear whether this is spec ambiguity, or a bug in the LSP / sourcekitd.