SwiftSyntax with Swift 5.1

Is a semantic version of the SwiftSyntax package for Swift 5.1 coming soon? @akyrtzi

While I wait, I have been toying with a fork in an attempt to get a head start on updating client code, but I have been running into trouble. I couldn’t find a swift-5.1-RELEASE tag, so I checked out swift-5.1-branch. Then I de‐GYB‐ified the package. In that state, it builds fine, and the tests pass in the package manager or with the result of generate-xcodeproj. However, if I open the package directly in Xcode by double‐clicking Package.swift, the built product (and anything that depends on it) is inoperable. The errors are all variations of this:

xctest (30953) encountered an error (Failed to load the test bundle. (Underlying error: The bundle “SwiftSyntaxTest” couldn’t be loaded because it is damaged or missing necessary resources. The bundle is damaged or missing necessary resources. dlopen_preflight([...]/Library/Developer/Xcode/DerivedData/swift-syntax-glexjgjummeedhaqfonfiovodnqm/Build/Products/Debug/SwiftSyntaxTest.xctest/Contents/MacOS/SwiftSyntaxTest): Library not loaded: @rpath/lib_InternalSwiftSyntaxParser.dylib
Referenced from: [...]/Library/Developer/Xcode/DerivedData/swift-syntax-glexjgjummeedhaqfonfiovodnqm/Build/Products/Debug/SwiftSyntaxTest.xctest/Contents/MacOS/SwiftSyntaxTest
Reason: image not found))

The same errors are inherited by client packages.

What is _InternalSwiftSyntaxParser, and where is it supposed to come from?

I wonder if this is something that can be fixed or worked around in the tagged release?

Until the SwiftSyntax team tags an official release, you can do what swift-format is doing and depend on the 2019-07-10 development snapshot; there weren't any incompatible changes to the syntax tree definitions between that and the final Swift 5.1 release.

I think this is a bug (?) in Xcode where it's not putting one of the toolchain's library directories in the binary's rpath correctly. I don't know if there's a better way to workaround it, but I just end up putting a symlink to lib_InternalSwiftSyntaxParser.dylib in the same directory as the executable so it'll find it, and that sticks around unless I clean the build product directory.


Aliasing lib_InternalSwiftSyntaxParser.dylib is sufficient to make Xcode work. I will probably stick with generate-xcodeproj for now for simplicity’s sake, but it is good to know it can be made to work and that nothing more serious is wrong.

However, once I got that “fixed”, I moved to the next step: Linux. There (both Ubuntu 16 and 18) my client tests consistently crashed when SwiftSyntax tried to unwrap the dlsym(_:_:) result in AtomicCounter.swift. I solved it by “breaking the rules” for _CSwiftSyntax, giving it a header and module map, and importing it normally. Whatever the issue was, it vanished.

How important is the “self-contained Swift module” nature of SwiftSyntax when it comes to the semantic version tags intended for consumption as a package? The rationale listed in the import directory is this:

Don't put headers here to import via the _CSwiftSyntax module. Swift does not support private module imports, meaning when distributing the SwiftSyntax.module we would also have to bundle these private headers as well.

But the distribution of headers seems unimportant in the case where everything is already managed automatically by the package manager. Would it be reasonable to include the extra headers alongside the GYB output just for those particular tags?

The dlsym issue has been fixed in master by this commit, which makes the _CSwiftSyntax module an @_implementationOnly import and thus no longer "leaks" it out of the module. Once they tag a release for 5.1, they should also pick up that change.

Thanks for bringing up these issues, I've opened a PR to fix the linux issue for 5.1.

A thing to keep in mind is that the SwiftSyntax library only depends on lib_InternalSwiftSyntaxParser.dylib being present and that library is self-contained, you can copy it out of the toolchain (e.g. if you have an app using SwiftSyntax you can bundle both SwiftSyntax and parser library within the app to make it relocatable).

1 Like

Also note that SwiftSyntax and parser library are generally version locked (e.g. 5.1 SwiftSyntax will require the 5.1 parser library) and if the loaded parser library is incompatible, SwiftSyntax will throw a parsing error.

@Xi_Ge created the 0.50100.0 tag, which includes the linux fix.


Thanks, Αργύριε!

1 Like

I'm trying to use SwiftSyntax on iOS 13 (Simulator) using Xcode 11.0 (11A420a) -- AppStore

I added SwiftSyntax using Xcode's GUI, and it indicates the version is 0.50100.0 as you commented just over a week ago.

-- What's the right tag to use for SwiftSyntax to get exactly the version in my current Xcode? I'm getting the following error:
Could not find or use auto-linked library '_InternalSwiftSyntaxParser'

To be clear: I'm not trying to Build Swift from Source, and my hello world-esque usage of SwiftSyntax successfully compiles, it just doesn't link!

Is it a fools errand to be attempting to get this to work on iOS? (I don't know if all the dependencies are able to compile on iOS at all!)

See my initial response here and recent update here.

Essentially you'd need to build the parser library for simulator (and device). The parser library inside the Xcode toolchain is only built for macOS.
If you checkout the swift-5.1-branch sources you can copy the build-parser-lib script from master and invoke it as I mentioned in the other forum thread.

1 Like

Thanks for the reply!! a primary goal of mine in today's experiments was to prove that it could work at all on iOS. -- I hadn't run across your other thread before now.

Terms of Service

Privacy Policy

Cookie Policy