[Swift] Initial support

[FichteFoll]

What happened?

There were several attempts to add a Swift syntax to the default packages before, but they failed because the quality of the syntax definitions were not up to par and there was not enough movement behind them to get them to a passable level (#11). Since the previous issue tracking this (#253) was closed, I'm opening a new one to gather community support, ideas, and to collect references.

Previous (publicly accessible) work:

• https://github.com/textmate/swift.tmbundle & https://github.com/jtbandes/swift-tmlanguage (for TextMate)
• https://packagecontrol.io/packages/Swift -> https://github.com/quiqueg/Swift-Sublime-Package
• adds Swift support #11 (based on "Swift for **ing Sublime package")
• https://github.com/GregoryBL/SwiftSyntax
• https://github.com/wbond/swift-for-sublime (WIP)

Going forward

The most promising Swift language definition was recently (2024-01) added to Package Control under the name of "Swift Next" and is maintained by @yaroslavyaroslav at https://github.com/Swift-Next/Swift-Next and was originally created by @aerobounce. @yaroslavyaroslav also voiced his support for eventually adding the package to the default packages and offered to help with that.

[jrappen]

@FichteFoll maybe pin this, too?

[yaroslavyaroslav]

So just to mention, there are few quite serious issues with the syntax that are spread across the whole its code, like this one for instance.

This exact one is occurred because of func definition takes anything that matches .whatever(. So it'd take a lot of effort to make things right even with the tests provided.

So I'd like to get acknowledged with DoD of this task from your perspective. Because if they're quite strict this will leads not just to adding a tests with some minor bug fixes meanwhile, but to some general refactoring.

[FichteFoll]

As I mentioned on Discord previously, in my opinion we can merge into a develop/ branch first and continue iterating on it until it has reached a certain level of maturity to be included as a default package¹. However, we would at least need some tests for the initial state to prevent regressions. They don't need to be as detailed as some of the tests we already have here, but should at least cover the basic functionality like some keywords, function definitions and various other basic syntax constructs.

Footnotes

1. which has no definition by itself and basically just requires two approvals by collaborators ↩

[yaroslavyaroslav]

Just an update of the swift syntax journey here.

1. It's Swift 6 coming this summer, which would has a breaking changes in syntax in it's release. So I believe it's worth to halt a test implementing process (which is barely started, lol) till at least I'll be able to look at those changes closer. The one that definitely would bring a mess there is an typed throw, and I believe the more to come.
2. I've implemented though quite raw yet iOS build system wrapper above sublime's Default.exec one. Building and launching iOS/macOS projects from without Xcode is a huge pain in the ass, that capturing a dozen number of steps to complete, but here we are.

[yaroslavyaroslav]

@FichteFoll speaking about syntax testing. One difficulty that I struggling with is the absence of knowledge "What's the right scope from ST should be really set on a given clause", i.e. the source of truth absence.

Recently we've got fixed LSP-Sourcekit semantic highlighting feature, so now LSP server sends its tokens, i.e. here's the source of truth coming.

So I look forward to rely on semantic highlight as a source of truth. Is a good practice here? Maybe you see some flaws along the path right away?

Here's the example of tokens provided by lsp server.

request.setValue(apiKey, forHTTPHeaderField: "x-api-key")
// <- variable
//       <- method, defaultLibrary

[jrappen]

I can send you a small PR to get you started with syntax testing in general if that helps.

You should only test what is defined in the syntax within the same repository. If you got stuff missing there but you want to take parts from LSP-Sourcekit, you should add (both) the syntax definition (as well as tests for it).

[yaroslavyaroslav]

I can send you a small PR to get you started with syntax testing in general if that helps.

Yeah, I'd really appreciate that