Add protocol-level @available annotation inheritance to generated mocks

[Keitaro0226]

Overview

Fixes #314

This draft PR addresses an issue where @available annotations on protocols are not inherited by the generated mock classes. This can cause compilation errors when the protocol uses types or members that are only available in specific OS versions.

Problem

Currently, when generating mocks for protocols with @available annotations, Mockolo does not apply these availability constraints to the generated mock. As a result, using the mock can trigger compile-time errors when availability-constrained types or members are involved.

Example

/// @mockable
@available(iOS 18.0, *)
protocol Foo: Sendable {
    func bar()
}

Incorrect mock (missing @available):

public final class FooMock: Foo, @unchecked Sendable { 
    // ❌ Missing @available
}

Correct mock:

@available(iOS 18.0, *)
public final class FooMock: Foo, @unchecked Sendable { 
}

Solution

• Extract protocol-level @available attributes and apply them to generated mocks.

Benefits

• Prevents availability-related compilation errors.
• Aligns mock generation with Swift’s availability system.

---

Open to feedback!

[CLAassistant]

All committers have signed the CLA.

[sidepelican]

Any updates on this? When this draft PR becomes ready?

[Keitaro0226]

Sorry for the long silence. I got sidetracked and lost track of this.

I'll add tests and mark this PR as ready soon. Thanks for your patience.

[sidepelican]

Thanks for the PR. Overall it looks good, but I noticed a few minor details that I'd like you to address before we merge.

[sidepelican]

I want to enforce a compilation error when @available isn't applied to a mock.

Suggested change

	/// @mockable
	@available(iOS 18.0, *)
	public protocol Foo: Sendable {
	func bar() -> String
	}
	@available(macOS 99.0, *)
	struct Bar {}
	/// @mockable
	@available(macOS 99.0, *)
	protocol Foo: Sendable {
	func bar() -> Bar
	}

[sidepelican]

Suggested change

// Combine protocol-level attributes with member-level attributes

The meaning feels a bit off and it’s redundant, so let's remove it.

[sidepelican]

It's strange for @mockable to come along too.
How about just inheriting available?
You can change EntityNode.attributesDescription requirement to var attributes: [String] { get }.

[sidepelican]

I need a test case for protocol inheritance scenarios:

@available(macOS 100.0, *)
struct Bar {}

@available(macOS 90.0, *)
protocol Foo {
}

/// @mockable
@available(macOS 100.0, *)
protocol Foo2: Foo {
  var bar: Bar { get set }
}