Prevent reduce function from being optimized

[AndrewBardallis]

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.

[stephencelis]

@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]

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]

@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.