Update `swift-syntax` to 603.0.x

[noefroidevaux]

Hello!

Firstly, thank you for creating such a great library!

I have experienced some performance issues since using the library. I tried to understand why, when I build my app, the compiler spends so much time on Emit Swift Module. I realised that this was due to swift-syntax performance issues. I tried updating the Swift syntax in your dependency, and it seems I don't have this issue anymore. Would it be possible to update the swift-syntax to version 603.0.x?

Thank you in advance!

[vnixx]

Hi, thanks for the report and PR!

I have a few questions and concerns before making this change:

1. Was this a clean build comparison?

When you observed the improvement after upgrading swift-syntax, did you compare clean builds (swift package clean + rebuild) in both cases? SPM caches compiled modules, so after any dependency change, the first build always recompiles everything from scratch. Subsequent builds use the cache. If you compared a cached build (post-upgrade) against a cold build (pre-upgrade), the results would be misleading.

2. Where exactly is the time spent?

Is the "Emit Swift Module" bottleneck happening in the swift-syntax module itself, or in your app/target code? This is a known issue with swift-syntax — it's a very large module and compiling it (especially in Release/WMO mode) is slow regardless of version. See:

• swiftlang/swift-syntax#1194 — swift-syntax compiles much more slowly with WMO
• swiftlang/swift-syntax#2414 — Build performance issue (swift-testing had the same complaint)
• swiftlang/swift-syntax#2421 — Request to distribute prebuilt binary

Could you share the build log or timing breakdown showing which target/module is consuming the time?

3. If it's swift-syntax compilation itself, consider using a prebuilt binary

If the bottleneck is compiling swift-syntax from source, upgrading the version won't fundamentally help. A better solution is using prebuilt swift-syntax binaries:

• swift-syntax-xcframeworks — prebuilt xcframeworks for each swift-syntax version
• This completely eliminates swift-syntax compilation time in your project

4. Why 603 specifically?

The 603.0.0 and 603.0.1 release notes contain no compilation performance improvements. 603.0.1 is literally a single commit fixing an explicit target dependency. Have you tried 601.x or 602.x? Did you see the same improvement?

For a library dependency, we generally prefer specifying the minimum version that satisfies the requirements. Jumping from 600.0.0 to 603.0.0 as minimum cuts off compatibility with users on Swift 5.10 toolchains (which ship with swift-syntax 600.x). Without a concrete reason why 603 is required (API change, bug fix, proven performance gain), this is an unnecessary compatibility break.

Summary

I'd be happy to merge this if we can confirm:

1. The comparison was done with clean builds
2. The time is actually spent in your app's compilation (not swift-syntax itself)
3. There's a specific reason 603 is needed vs 601/602

Otherwise, the better path for users experiencing slow swift-syntax compilation is to use prebuilt binaries rather than bumping the minimum version requirement.

[noefroidevaux]

Hi @vnixx ,

Thanks for your message. I completely understand the reasoning that a library dependency should be at the minimum version 👍

Some info about the project I use:
Xcode 26.5 / Swift 6.3.2
SWIFT_STRICT_CONCURRENCY: complete
SWIFT_VERSION: 6.0
It's a quite huge project and I use ReerCodable in ~250 files

1. Was this a clean build comparison?

No, in fact, the problem is in the incremental build. Here is the results I have for each cases.

Emit Swift Module part (for the app) times:

with 600.0.1 + clean + build: 0.2s
with 600.0.1 incremental build without changes: 0.1s
with 600.0.1 incremental build with a change in a source file: 28s

with 603.0.1 + clean + build: 0.2s
with 603.0.1 incremental build without changes: 0.1s
with 603.0.1 incremental build with a change in a source file: 17s

So I have an 11-second difference by changing the version that I can't explain. Maybe it's because I'm using Swift 6.3 and swift-syntax 600.0.x is designed for Swift 6.0.x? I have also ~17s if I remove ReerCodable/SwiftSyntax from the project, like if I use the version 603.0.1 .

2. Where exactly is the time spent?

It's difficult to say as it's time spend in "Emit Swift Module for xxx" (xxx = the app name) part... I also can't explain why the Emit Swift Module part is fast after a clean. The total build time is clearly longer than for incremental builds. But for Emit Swift Module, it's shorter… Maybe during incremental builds, there are things done in Emit Swift Module (which is quite a blackbox...) that are explicitly shown in a build after a clean.

3. If it's swift-syntax compilation itself, consider using a prebuilt binary

As I understood https://github.com/sjavora/swift-syntax-xcframeworks#clashes-with-swift-syntax , we could do that, but it would have to be implemented as a dependency in ReerCodable, right? And it seems Apple do the pre-build now and it's activated by default since Xcode 26.0.

4. Why 603 specifically?

I have the following time for Emit Swift Module on incremental build (with a change in a source file):

601.0.1: 27s
602.0.0: 26s

But I’d turn the question around: why stick with version 600.0.x (without a option to update), which is almost two years old? Maybe it would be a good idea to set from: 600 and let the user choose the version as needed?

[vnixx]

@noefroidevaux Thank you for your detail response, I've merge the pull request, and released 1.7.3

[noefroidevaux]

Thank you @vnixx 👍

I just tested my app with version 1.7.3 of ReerCodable, and I’m seeing a time savings of over 11 seconds on incremental builds 🚀

Looking ahead, I wonder if the library shouldn't be more flexible about swift-syntax versions (with from: 600)? Especially with WWDC coming up and probably new Xcode/Swift versions 🙂

[vnixx]

@noefroidevaux The WWDC logo this year looks very Swift-like, so maybe we’ll see some bigger Swift/Xcode changes than usual

I’ll keep an eye on the new toolchain updates after WWDC.
If you have any ideas around this, or if anything changes after WWDC, I’d be happy to discuss it together.

[noefroidevaux]

@vnixx Yes, it seems so 🙂 I'll keep an eye on it too 👍