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
	}

[Keitaro0226]

Fixed in 2fa6c3d.
I updated the fixture to use an availability-gated return type (Bar) so the generated mock must inherit @available to compile.

[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.

[Keitaro0226]

Fixed in 3e51751.
Removed the redundant comment.

[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 }.

[Keitaro0226]

Fixed in 7f3a38b.
I changed declaration attribute handling to keep syntax attributes as separate entries, so @mockable trivia no longer gets carried along with @available.

[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 }
}

[Keitaro0226]

Fixed in 32dffb1.

[Keitaro0226]

Thank you for the review.
I’ve addressed the feedback and pushed the updates. I’d appreciate it if you could take another look when you have a chance.
Thank you.

[sidepelican]

Sorry for the late review.
It looks good. Thank you for your contribution!