Unbound memory growth when using existential with primary associated type in SwiftUI view

[mbrandonw]

Description

I filed this bug in Feedback (FB12101395) as currently I've only been able to reproduce it in SwiftUI, but it does seem like a Swift bug in general.

Run the following code in a simulator, tap the “Go” button, and notice that the application freezes:

import SwiftUI

struct ContentView: View {
  var body: some View {
    NavigationStack {
      NavigationLink("Go") {
        DemoView()
      }
    }
  }
}

protocol Foo<A> {
  associatedtype A
}
struct Bar: Foo {
  typealias A = Int
}

struct DemoView: View {
  let foo: any Foo<Int> = Bar()
  var body: some View {
    EmptyView()
  }
}

If you open the Debug Navigator in Xcode you will notice that the memory keeps growing.

This happens in Xcode 14.2+Swift 5.7 as well as Xcode 14.3+Swift 5.8.

Steps to reproduce

Run the above in a SwiftUI application.

Expected behavior

Tapping the "Go" button should drill down to the destination.

Environment

• swift-driver version: 1.75.2 Apple Swift version 5.8 (swiftlang-5.8.0.124.2 clang-1403.0.22.11.100)
  • This also happens in Swift 5.7
• Xcode 14.3, Build version 14E222b
  • This also happens in Xcode 14.2
• iOS 16+

[AnthonyLatsis]

Do you mean to say the app will stop freezing if you replace let foo: any Foo<Int> with let foo: any Foo?

[mbrandonw]

Hi @AnthonyLatsis, yes that will fix it, or if you replace any Foo<Int> with a concrete type eraser AnyFoo<Int>.

Since posting this I've done a bit more experimentation and think it's more heavily involved with SwiftUI, though it could still be a purely Swift bug. If you put a print statement inside the body of DemoView you will see it is called in an infinite loop. So somehow the existential with primary associated type is tripping up SwiftUI to recompute its body over and over.

[AnthonyLatsis]

If you put a print statement inside the body of DemoView you will see it is called in an infinite loop.

I see, thanks for the input. I highly doubt the infinite loop has to do with code generation rather than SwiftUI control flow. But assuming so, I think the reason control finds its way into this unguarded infinite loop (which is certainly a bug in itself) might be related to some kind of reflection issue with constrained existentials.

[mbrandonw]

Yes, that's what I am thinking too. I also just recently figured out that this only reproduces inside a NavigationStack and not a NavigationView. So that might help Swift/SwiftUI engineers track it down further.

[iampatbrown]

@mbrandonw the view's equatability may be contributing.

These two work arounds worked for me:

struct DemoView: View, Equatable {
  var foo: any Foo<Int> = Bar()

  var body: some View {
    EmptyView()
  }
  
  static func == (lhs: DemoView, rhs: DemoView) -> Bool {
    true
  }
}

@propertyWrapper
struct AlwaysEqual<Value>: Equatable {
  var wrappedValue: Value

  static func == (lhs: AlwaysEqual<Value>, rhs: AlwaysEqual<Value>) -> Bool {
    true
  }
}

struct DemoView: View {
  @AlwaysEqual
  var foo: any Foo<Int> = Bar()

  var body: some View {
    EmptyView()
  }
}

I could also reproduce the issue with the following:

struct DemoView: View, Equatable {
  var foo: any Any = ()
  
  var body: some View {
    EmptyView()
  }
  
  static func == (lhs: DemoView, rhs: DemoView) -> Bool {
    false
  }
}