You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Building in Xcode vs. terminal or ARM vs. x86 seems to make no difference.
Additional Detail from JIRA
Votes
0
Component/s
Compiler
Labels
Bug
Assignee
None
Priority
Medium
md5: fc2863e2d1f0bc92b5a9ae41690dff09
Issue Description:
A series of type aliases, each with a single parameter, is used to construct a deeply recursive type. As the size of the nested type increases, the compiler takes slightly longer to run. At a certain size (about 16 levels deep), the compiler hangs indefinitely.
According to Activity monitor, `swift-frontend` is pegging a single core, with memory stable at about 35 MB.
This issue seems to make it pretty hard to use this approach to define compile-time natural numbers. I ended up using a different encoding instead for what I needed (which was actually just the numbers 0 to 63.)
protocolNat {}
enumZero: Nat {}
enumSucc<Pred: Nat>: Nat {}
typealiasOne = Succ<Zero>
typealiasPlus1<T: Nat> = Succ<T>
typealiasPlus2<T: Nat> = Plus1<Plus1<T>>
typealiasPlus4<T: Nat> = Plus2<Plus2<T>>
typealiasPlus8<T: Nat> = Plus4<Plus4<T>>
/// The compiler hangs if this type alias is **used**, but not if this declaration appears but is never applied:typealiasPlus16<T: Nat> = Plus8<Plus8<T>>
/// However, this seems to be fine:typealias_64 = Succ<Succ<...<Zero>...>>
The package will build, but the compiler hangs when a test tries to apply that alias:
At first, this reminded me of https://bugs.swift.org/browse/SR-1312 but that is actually different as we end up with high memory consumption there but not here.
Environment
macOS 11.4
Mac mini (M1), 16 GB
Xcode 12.5.1
Swift 5.4.2
Building in Xcode vs. terminal or ARM vs. x86 seems to make no difference.
Additional Detail from JIRA
md5: fc2863e2d1f0bc92b5a9ae41690dff09
Issue Description:
A series of type aliases, each with a single parameter, is used to construct a deeply recursive type. As the size of the nested type increases, the compiler takes slightly longer to run. At a certain size (about 16 levels deep), the compiler hangs indefinitely.
According to Activity monitor, `swift-frontend` is pegging a single core, with memory stable at about 35 MB.
This issue seems to make it pretty hard to use this approach to define compile-time natural numbers. I ended up using a different encoding instead for what I needed (which was actually just the numbers 0 to 63.)
A Swift package exhibiting the problem can be found at https://github.com/mossprescott/swift-bug-recursive-types.
The offending code is:
The package will build, but the compiler hangs when a test tries to apply that alias:
The text was updated successfully, but these errors were encountered: