Linking error in Release mode

[rcarver]

Hoping someone can explain what's going on here. In prepping some work for a Release build, I got some strange build errors. These only show up in a Release build. Debug works fine.

Undefined symbols for architecture arm64:
  "_$s18FirstLaunchFeature011WelcomeBackC0V4CoreV22ComposableArchitecture15ReducerProtocolAAWP", referenced from:
      _$s22ComposableArchitecture17_IfCaseLetReducerV6reduce4into6actionAA15EffectPublisherVy6ActionQzs5NeverOG5StateQzz_AJtFACy18FirstLaunchFeature011WelcomeBackQ0V4CoreVAP0R6ScreenVG_AP012UpgradeOfferU0VTgq5 in AppFeature.o
  "_$s18FirstLaunchFeature011WelcomeBackC0V4CoreVN", referenced from:
      _$s22ComposableArchitecture17_IfCaseLetReducerV6reduce4into6actionAA15EffectPublisherVy6ActionQzs5NeverOG5StateQzz_AJtFACy18FirstLaunchFeature011WelcomeBackQ0V4CoreVAP0R6ScreenVG_AP012UpgradeOfferU0VTgq5 in AppFeature.o
ld: symbol(s) not found for architecture arm64

Here's the failing type:

public struct WelcomeBackFeature: ReducerProtocol {
  public enum State: Equatable {
    case welcomeScreen(WelcomeScreen.State)
    case upgradeOfferScreen(UpgradeOfferScreen.State)
    init() { self = .welcomeScreen(.init()) }
  }
  public enum Action: Equatable {
    case welcomeScreen(WelcomeScreen.Action)
    case upgradeOfferScreen(UpgradeOfferScreen.Action)
  }
  public var body: some ReducerProtocol<State, Action> {
    Core()
      .ifCaseLet(/State.welcomeScreen, action: /Action.welcomeScreen, then: WelcomeScreen.init)
      .ifCaseLet(/State.upgradeOfferScreen, action: /Action.upgradeOfferScreen, then: UpgradeOfferScreen.init)
  }
  struct Core: ReducerProtocol {
    func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
      switch action {
      case .welcomeScreen(.welcomeMessageContinueButtonTappped):
        state = .upgradeOfferScreen(.init())
        return .none
      case .upgradeOfferScreen:
        return .none
      }
    }
  }
}

(Side note: I've been exploring this pattern of a nested Core reducer type as opposed to a core property and liking it)

---

After much trial and error, the fix is to make WelcomeBackFeature.Core public. But why?

  public struct Core: ReducerProtocol {
    public func reduce(into state: inout State, action: Action) -> EffectTask<Action> {

I haven't yet figured out how to reproduce this in a new project, nor with a minimal new feature in the same project. Starting with this, where does the problem come from?

public struct CoreContainingFeature: ReducerProtocol {
  public struct State: Equatable {
  }
  public enum Action: Equatable {
  }
  public var body: some ReducerProtocol<State, Action> {
    Core()
  }
  struct Core: ReducerProtocol {
    func reduce(into state: inout State, action: Action) -> EffectTask<Action> {
      return .none
    }
  }
}

[tgrapperon]

Hey @rcarver. This is a bug I've noticed a few months ago. Swift optimizer sometimes prunes non-public nested types that are only referenced in @ResultBuilders functions, like ReducerProtocol and SwiftUI's bodys.

I didn't manage to reproduce it in a standalone project, and I forgot to report it.

It can bite you really easily with internal or private enums that you're using as identifiers. That's why I'm now declaring them as public and relocate them in the reducer itself, beside State and Action.

We should definitely find a repro and report it properly, as the issue will occur more and more given the way we organize features nowadays.

[tgrapperon]

We can probably use a dependency to provide contextualized identifiers with a simple subscript:

@Dependency(\.id["fetchRequest"]) var fetchRequestID

If we wire this thing to navigation-beta's NavigationID, we can even avoid cross-cancellation like it can happen in document apps.

[rzulkoski]

@stephencelis Sorry I wasn't more clear: I was bit by the compiler pruning an internal type, which was NOT an identifier. In my use case the user hands me an identified array of a public item type, which I transform into an identified array of an internal type. I don't have time at the moment to elaborate, but this post helped me pinpoint the issue, although the pruned type was a different use-case entirely.

[tgrapperon]

Was it only referenced in some resultBuilder decorated function/variable, like some View's body or some ReducerProtocol's body?

[rzulkoski]

It was a private enum used as an internal property of a public ReducerProtocol’s State. The fix was to make the enum public, and I was able to keep the property marked as internal.

[tgrapperon]

OK, thanks! I was thinking this was related to uses in @resultBuilder that weren't spotted and then pruned at the optimisation phase, but I'm not sure anymore after your report. Is this property accessed (only) from within a reducer's body, or are you touching it through some ViewStore's observing { $0 }?

[JimRoepcke]

Has anyone submitted a feedback on this yet? We've been bit by this problem as well.

[tgrapperon]

I didn't because I wasn't able to extract a repro, and I didn't want to submit a bug report without it.

[jgoodrick]

Just a heads up, I ran into exactly this due to an internal struct (that conformed to the ReducerProtocol) where its State and Action types were just internal typealiases of a parent reducer, as well. Making the struct and its State/Action public fixed it immediately.