[Bug] Generics syntax is incorrectly generated from protocols that have associated types with multiple conformances

[ngimelliUW]

Swift Version

6.0

Package Version

0.1.0

Bug Description

It may be desirable to generate a mock from a protocol with associated types. Sometimes, those associated types may themselves have multiple conformances. For example:

public protocol InMemoryStoreProtocol: Sendable {

    associatedtype Key: Hashable & Sendable
    associatedtype Value: Sendable

    ...
}

in this case, we require that both the key and the value be sendable. The key has the additional requirement of being hashable. However, if you add the @Mocked macro to this protocol, it will generate the following:

public final class InMemoryStoreProtocolMock<Key:, Value: Sendable>: InMemoryCacheProtocol { ... }

You can see that the Key generic argument is succeeded by a colon, but does not actually list any required conformances (like Value does with Sendable)! This only happens when the associated type has multiple conformance requirements.

Steps to Reproduce

1. Create a protocol that has an associated type.
2. Add multiple conformance requirements on that associated type using & syntax.
3. Expand the macro; you will see the bug.

Code of Conduct

• I agree to follow this project's Code of Conduct

[nolinmcfarland]

Nice catch! I was able to reproduce the issue and did a quick investigation. Here's what I found:

Multiple inheritance is handled correctly when each inherited type is comma-separated. For example:

@Mocked
public protocol Dependency: Sendable {
    associatedtype Key: Hashable, Sendable
    associatedtype Value: Sendable 
    ...
}

However, the bug occurs when using composition (&) in inherited types, like in your example.

The bug is in MockedMacro.mockGenericParameterClause, where we’re checking for inherited types using IdentifierTypeSyntax. This works when an associated type inherits from a single or multiple comma-separated types. However, for composition (&), the syntax changes: instead of individual InheritedTypeSyntax nodes, we get a CompositionTypeSyntax composed of multiple IdentifierTypeSyntax elements. So for those cases, we need to dig one level deeper to construct the clause correctly.

I’ve drafted a fix and can open a PR to discuss the approach. I’ll also add unit tests to cover this case going forward.