Description
Problem
The build tasks that vscode-swift
generates include "-Xswiftc" "-diagnostic-style=llvm"
in their arguments.
When the user builds on the command line, they are likely to just do swift build
, swift test
etc.
My assumption is that the build cache may be invalidated by SPM when the command line arguments change. There is no way to know for certain for any given arguments (other than reading the SPM source code), but it is a safe assumption that it could (and probably should) happen for some of them.
This isn’t ideal as it could cause a certain amount of thrashing for anyone who is used to switching back & forth between building in the IDE and the command line. For packages using macros or other large dependencies with long build times, this is a real annoyance.
Possible Solutions
Initially it would be useful if this was clearly documented, so that users were at least aware of the problem. Do we need to pass the same arguments on the command line to avoid a full rebuild every time?
Preferably, vscode-swift
should use the same defaults as the command line, and not specify explicit extra options.
Alternatively, if it needs non-default arguments, it should offer to add them to the Package.swift
file, so that a build triggered in any manner ought to produce the same results.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status
Activity
samdeane commentedon Jan 30, 2025
Possibly, this issue should just be called "Make swift-vscode use default build arguments` -- if that is a feasible solution.
award999 commentedon Jan 30, 2025
The
llvm
diagnostics allow for the extension to parse better diagnostics from swift build tasks. You can set theswift.diagnosticsStyle
setting to default and the-diagnostic-style
will no longer be set. You may then lose some of the nested, related hints for certain diagnosticssamdeane commentedon Jan 30, 2025
For the record: changing this setting does not alter the behaviour of any task that has been written into
tasks.json
by the plugin.Which is obvious if you know about that mechanism, but not if you don't.
Having the plugin write tasks into
tasks.json
isn't strictly required, but can happen semi-by-accident. For example if you select an extension-generated task to be the default build task, a copy of it is exported totasks.json
, and that is set to be the default.Much of this is probably the fault of VSCode's architecture, but it results in a non-optimal UX for the extension. It makes me wonder whether the extension-generated task should invoke an intermediate process which injects the extra settings, rather than them being explicitly written into the task.
samdeane commentedon Jan 31, 2025
See also this slack thread for context.
award999 commentedon Feb 5, 2025
Ya unfortunately the writing to tasks.json happens through built-in vscode mechanisms, not anything the extension does. As I mentioned on Slack, I'd set
swift.diagnosticsStyle
todefault
. You'll still get all the diagnostics and related information from SourceKit-LSP. You'd only not get the related information for diagnostics from parsing build tasks, but this has no effect on the errors from source kit LSP when you type. If the default diagnostics improved one day in swiftc, then we could drop setting thellvm
diagnostic style.plemarquand commentedon Jun 17, 2025
The underlying issue is that SwiftPM should not rebuild if build arguments change that don't affect build artifacts. I've attempted to fix this in SwiftPM with swiftlang/swift-package-manager#8803.
Fix diagnostic parsing when spaces in file name
Fix diagnostic parsing when spaces in file name
Fix diagnostic parsing when spaces in file name
Fix diagnostic parsing when spaces in file name
Fix diagnostic parsing when spaces in file name (#1633)