Inconsistent Crash while resolving
SlashDevSlashGnoll opened this issue · 4 comments
We're seeing a crash in DIP when creating the initial view controller which through it's references winds up trying to resolve a type which results in a crash. This type can be described as such (using made-up names to simplify):
struct Configuration {}
protocol Foo {}
open class SuperClass: Foo {
var configsByUser: [String: Configuration] = []
}
class SubClass: SuperClass {}
We register SubClass
into the dependency container using the type Foo
. When we resolve, there seems to be a crash at
Dip/Sources/AutoInjection.swift
Line 48 in 0193aa6
In this specific case it seems to be trying to deal with the property configsByUser
above. In the debugger I am able to see the following:
(lldb) po type(of: child.value)
Swift.Dictionary<Swift.String, Configuration>
It seems that the data in the Mirror is neither AutoInjectedPropertyBox
nor ImplicitlyUnwrappedOptional
. Accessing child.value
at all seems to crash as the debugger cannot do anything with it beyond querying the type as far as I can tell. I saw https://bugs.swift.org/browse/SR-2282 that you filed but that doesn't seem to be the same issue.
I'm unsure if this shows a problem with how things are registered or what but I wasn't sure how to chase this further. Any input would be greatly appreciated as this error happens very frequently in the simulator which is destroying our automated testing. We do not think we've seen this at all on an actual device so that could be another data point.
Ah I should also note that we are building with Xcode 11.0 and this issue started during our conversion on the Beta this summer so it seems to be new to this version of the compiler.
If you don't use autoinjected properties you can disable them until this is resolved (if it still happens with GM?). See a8777c0
@SlashDevSlashGnoll is this still relevant?
Turning off autoinjected properties avoids the problem for us yes. Thanks for the advice. It feels like there's still an issue in there but since we didn't need that feature we could just disable it.
Sorry for not reporting in earlier!