Make -diagnostic-style consistent between CLI and IDE builds

[samdeane]

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.

[samdeane]

Possibly, this issue should just be called "Make swift-vscode use default build arguments` -- if that is a feasible solution.

[award999]

The llvm diagnostics allow for the extension to parse better diagnostics from swift build tasks. You can set the swift.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 diagnostics

[samdeane]

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 to tasks.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]

See also this slack thread for context.

[award999]

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 to default. 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 the llvm diagnostic style.

[plemarquand]

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.