Open s-hocking opened 3 years ago
A workaround for the producesBadCode
issue (missing inferred generic type specialization) is to keep the member declarations the same (referencing the inherited generic types) and use generic type constraints instead. So for the example above, MyOtherProtocol
would look like the following:
protocol MyOtherProtocol: MyProtocol where U == MySubtype, T == String {
func producesBadCode(input: U) -> [T]
}
To be honest, it it better to write verbose code than this library which is unpredictable in many scenarios and there is basically no support at all. Let alone support there is not even a single example for protocols with generic types. So dump this and write your own mocks as simple as that
New Issue Checklist
Description
With my particular class and protocol setup, using associated types, Mockingbird either generates a mocks that doesn't compile or a mock that crashes the Swift compiler, depending on my function's return type.
Generator Bugs
If the generator produces code that is malformed or does not compile, please provide:
This source can produce either non-compiling mocks or a Swift compiler seg fault, depending which set of functions you comment out:
I think the issue is the duplicate function definitions in
class MyOtherProtocolMock
. Maybe this is related to #183 ? When removing the dupes the broken mock compiles:Environment
mockingbird version
) - 0.16.0swift --version
): Apple Swift version 5.4 (swiftlang-1205.0.26.9 clang-1205.0.19.55), Target: x86_64-apple-darwin20.3.0.mockingbird-ignore
? - No