Problem
Currently, when a protocol has @available annotations, the generated mock classes do not inherit these availability constraints. This leads to compilation errors when using the mocks in contexts where availability-constrained types or members are involved.
Example
Input protocol:
/// @mockable
@available(iOS 18.0, *)
public protocol Foo: Sendable {
func bar()
}
Incorrect generated mock:
public final class FooMock: Foo, @unchecked Sendable { // ❌ Missing @available
// Mock implementation...
}
Expected mock:
@available(iOS 18.0, *)
public final class FooMock: Foo, @unchecked Sendable {
// ✅ Correct
}
Real-world Impact
When the generated mock lacks the appropriate @available annotation, any reference to types or members that require specific OS versions results in compile-time errors, even in purely test contexts.
Environment
- mockolo version: 2.4.0
- Xcode version: 16.4
- Swift version: 6.0+
Proposed Solution
Enhance mock generation to:
- Extract protocol-level
@available annotations
- Apply them to the generated mock class
A draft PR is already available for this feature, and I would appreciate feedback based on that proposed approach:
Draft PR:
Thank you for your time and consideration!
Problem
Currently, when a protocol has
@availableannotations, the generated mock classes do not inherit these availability constraints. This leads to compilation errors when using the mocks in contexts where availability-constrained types or members are involved.Example
Input protocol:
Incorrect generated mock:
Expected mock:
Real-world Impact
When the generated mock lacks the appropriate
@availableannotation, any reference to types or members that require specific OS versions results in compile-time errors, even in purely test contexts.Environment
Proposed Solution
Enhance mock generation to:
@availableannotationsA draft PR is already available for this feature, and I would appreciate feedback based on that proposed approach:
Draft PR:
Thank you for your time and consideration!