Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

Prevent reduce function from being optimized #3683

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

AndrewBardallis
Copy link
Contributor

Description

Ever since Swift 6 (i.e. TCA 1.15.0) there exists an issue in the Swift compiler that can lead to crashes only when the app has been archived for release. Greater detail was documented in this discussion.

Unfortunately, we have still been unable to identify the conditions in which the crash occurs so it makes reproducing the issue prohibitively difficult in a sample app (making testing this PR difficult for someone not experiencing the crash).

However, we were able to pare down our production application considerably and share this with Apple developer support who were also able to reproduce the issue. They've acknowledged this to be an issue rooted in the Swift compiler.

Below is the latest response from the internal email thread we've had open with developer support:

Engineering has identified the specific point of failure in this code. It appears to be a compiler bug. To mitigate this issue, you can disable optimizations for the problematic function by using the following code:

extension Reducer where Body: Reducer<State, Action> {
  /// Invokes the ``Body-40qdd``'s implementation of ``reduce(into:action:)-1t2ri``.
  @inlinable
  @_optimize(none)
  public func reduce(
    into state: inout Body.State, action: Body.Action
  ) -> Effect<Body.Action> {
    self.body.reduce(into: &state, action: action)
  }
}

At Apple, we are unable to disclose any information regarding upcoming releases. However, we can assure you that the bug will be addressed in future releases. We recommend that you monitor your FB number for updates regarding the bug’s resolution.

Changes:

  • Adds @_optimize(none) to reduce(into:action:) per Apple's guidance to mitigate crashes.

Testing:

As mentioned, testing this can be rather difficult if you don't already have an app that exhibits the issue. We were able to clone the latest TCA release, add it as a local dependency, make the change, and verify that the crashes no longer occurred on archived release builds.

Copy link
Member

@stephencelis stephencelis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AndrewBardallis Thanks for diving into this. Have you or can you open an issue on the Swift compiler that we can follow? It's a bummer to lose optimizations here, so it's be nice to have insight into when the bug is fixed so we can bring them back.

@stephencelis
Copy link
Member

Also, since we don't have a way of reproducing, could you give us an update when the next Xcode is released to see if it's fixed there? Then we can proactively scope things with an #if compiler check.

@AndrewBardallis
Copy link
Contributor Author

@stephencelis Absolutely. Following up to see if there was an issue created. They were pretty opaque about the details, instead just offering the mitigation, so I'm not terribly hopeful there's an existing open issue or anything meaningful I'd be able to put in one. Will let you know if there is.

They did say they'll follow up in the FB when it's fixed so we'll absolutely keep an eye on that as well as test again with each new version of Xcode.

@AndrewBardallis
Copy link
Contributor Author

@stephencelis @mbrandonw Now that this PR has been approved, is there a process that you typically follow for merge/release? Not trying to be pushy, just trying to get a rough idea on timing so that we can estimate upcoming availability of developer bandwidth and when we'll be able to get off of 1.12.1.

I also confirmed with Apple Dev Support that this is only being tracked internally via FB16628389. We'll check for updates on that regularly and retest with new Xcode releases and keep you in the loop. Thank you!

@stephencelis
Copy link
Member

@AndrewBardallis We will chat about this today. Did you ever open up a public issue in the Swift repo that references the feedback? This seems like a compiler issue so it'd be nice to be able to track this in a public way since Feedback is so opaque.

@stephencelis
Copy link
Member

@AndrewBardallis We'll merge this as-is, but please do follow up with a Swift GitHub issue that we can track and link to!

@stephencelis stephencelis merged commit 294ac2c into pointfreeco:main May 22, 2025
14 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.