Fix parameter pack compiler crash related to tuple_pack_element_addr call
#85975
+410
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Full disclosure: This code was almost entirely written by Claude. I ran into a compiler crash, thought I'd have Claude take a crack at fixing it (very skeptical that it would), and as far as I can tell, it has actually fixed the issue.
That said, this is pretty far outside of my area of expertise. If this PR is against contributor guidelines or so bad that it's not at all usable, I will happily close it. I'm not here to take a moral stand on AI. I just want the bug fixed.
I also know my commit messages are lacking. I plan on squashing before I merge.
Issue
The following code causes a compiler crash on the version of Swift that ships with Xcode 26.1. I have confirmed it also crashes when run with the latest
mainbranch by building the compiler locally and using it to execute the repro case.Repro
Crash stack trace
This is from the Swift Development Snapshot on December 1st
Fix
Looks like the issue is that there are some portions of the codebase that don't guard against parameter packs, and therefor treat them as normal, multi-element tuples.
Here's how Claude described the fix (edited for brevity).
Parameter packs have unknown arity at compile time, which breaks the assumptions of the
DefiniteInitialization (DI) pass.
Consider the Codable struct that was crashing:
The tuple
(repeat each Input)could have 0, 1, 5, or any number of elements depending on how it's instantiated:Coder<Int>→ 1 elementCoder<Int, String, Bool>→ 3 elementsCoder<>→ 0 elements (empty pack)DI's element-counting logic (
getElementCountRec) was trying to iterate the tuple's elements and assign fixedindices, but you can't assign static indices to a dynamically-sized structure.
The Solution
Treat the entire pack-expansion tuple as one opaque unit:
This means:
(repeat each Input)tuple as a single "blob"tuple_pack_element_addr(which takes a dynamicindex)
// End Claude explanation
Addendum
This crash is very very particular. The repro case must do all of the following.
Here is as far as I've pared down the crash case