protocol Delegate<T> {
associatedtype T
func f(t: T)
}
class ConcreteClass: Delegate {
func f(t: Int) { }
}
class A<T> {
private let delegate: any Delegate<T>
init(delegate: any Delegate<T>) {
self.delegate = delegate
}
}
let a = A(delegate: ConcreteClass())
It runs fine in Debug mode but crashes in Release mode (or if optimization level is Optimise for Speed [-O])
The crash is:
#0 0x0000000100003b49 in outlined init with take of any Delegate<Self.Delegate.T == Int> ()
#1 0x0000000100003ac4 in specialized A.init(delegate:) [inlined] at /Users/plamen/Projects/Tests/TestCrash2/TestCrash2/main.swift:25
#2 0x0000000100003ab7 in specialized A.__allocating_init(delegate:) [inlined] at /Users/plamen/Projects/Tests/TestCrash2/TestCrash2/main.swift:24
#3 0x0000000100003a96 in main at /Users/plamen/Projects/Tests/TestCrash2/TestCrash2/main.swift:29
#4 0x000000010001952e in start ()
I am with the latest Swift 5.7 version on macOS (Xcode 14.0.1)
Any ideas why it happens? Is it bug in the optimizer or I am not using properly protocol primary associated types?
Even if there’s something subtly wrong with your usage here (and it doesn’t look to me like there is), it should lead to a compiler error and not a crash. Definitely file an issue on GitHub!
I am right now in the middle of trying to track down a compiler crash that could be related to primary associated types (I haven't come up with a simplified case yet). I have reported it. It happens in Xcode 14.1 beta 3 as well.
It's a pain because if I comment out my function where the log says the compiler is crashing, then it crashes in a different, seemingly very unrelated function instead. An so on.
No, nothing wrong that I can see. My only point was that if there is some subtle issue that I'm not noticing, it should manifest as a compile-time error rather than a runtime crash in only certain optimization modes.
To me, looks more like there's a miscompilation of some sort going on.
my understanding is that the generics system was recently rewritten (which is a good thing, because the purpose of the rewrite was to improve compile times, something that’s been dogging this community for years now), but that also generated a staggering wave of compiler crashes starting around the beginning of summer 2022 or so.
not sure if there’s anything that can be done other than wait for the problems to subside, as happened in the past when async/await was first introduced, or before that when conditional conformances were first introduced.
my guess is we will be back to baseline “crashiness” this winter or spring 2023. (for what it’s worth, this is not a particularly severe crasher season by historical standards. fall 2021 was much, much worse.)