Fix associatedtype generics

[art-divin]

Resolves: #1333

Description

This MR introduces a correct way of generating mocks for associatedtype in a protocol marked as AutoMockable.

Context

Previously, Sourcery was not generating a compilable mock if a mockable protocol had associatedtypes used as arguments or return values or types for variables in that protocol.

The reason was both that during processing, protocol's generic requirements for associated types were not stored, and that a protocol was not checked if it had associated type or not.

Now, AutoMockable.stencil contains logic to check if there are both associated types and generic requirements for those types in a protocol or not.
Now, if an associated type has a primitive type, and not a protocol, a typealias is injected into the mockable type. When an associated type has a protocol type, then that type is:

• migrated to Generic constraint of the generated type
• preserving and specifying generic requirements, if any

Example

Input

//sourcery:AutoMockable
protocol TestProtocol<SomeType> {
    associatedtype SomeType: Sequence where Value.Element: Collection, Value.Element: Hashable, Value.Element: Comparable

    func getValue() -> SomeType

    associatedtype Value2 = Int

    func getValue2() -> Value2
 }

Output

class TestProtocolMock<
    SomeType: Sequence>: TestProtocol
    where SomeType.Element : Collection, SomeType.Element : Hashable, SomeType.Element : Comparable {
    typealias Value2 = Int

    ...
}

[liamnichols]

@art-divin i'm digging into a regression that I have run into and I want to confirm if this change is the culprit or not...

I have the following example:

protocol FooValue {}

protocol Foo {
    associatedtype Bar: FooValue
    var value: Bar { get }
}

class Baz {
    struct Bar {
    }

    let bar: Bar

    init(bar: Bar) {
        self.bar = bar
    }
}

For the Bar associated type inside the Foo protocol, this change causes typeMap["Bar"] to be set to FooValue.

When I dump the parsed AST for Baz, I get expected values from the type of the stored variable, but I get the wrong type from the initialiser parameter:

(lldb) po result.first!.storedVariables.first!.typeName!.name
"Baz.Bar"
(lldb) po result.first!.initializers.first!.parameters.last!.type!.name
"FooValue"

I have a hunch that the issue comes in two parts:

1. The initializer parameter type isn't getting the global name assigned to its typeName the same way that the store variable does:

   (lldb) po result.first!.storedVariables.first!.typeName
   Baz.Bar
   (lldb) po result.first!.initializers.first!.parameters.last!.typeName
   Bar
   

2. Associated types are being treated as globals which is a potential cause for conflict

I can try to dig further, or put this into an issue, but I wanted to check to see if this is something that you're actively aware of atm?

Thanks!

[art-divin]

Hello @liamnichols ,

amazing work! Very nice of you sharing this 🤝

I have a hunch that the issue comes in two parts:

Sounds like it, there were and still are a number of features related to associated types which are not supported at all.
Previously they were completely ignored when mocks were being generated during to missing metadata.

I can try to dig further, or put this into an issue, but I wanted to check to see if this is something that you're actively aware of atm?

If you can, sure, that would be awesome -> creating an issue, digging further... Sounds like a plan!
To answer your question, I am not aware of this regression and I really appreciate the code sample of things not working as expected in your comment here.

If you would be able to at least provide "Expected" and "Actual" sections in your issue, say, if you cannot fix this at your convenience,
it would play a crucial role in speeding up the investigation and the fix in future. 🙏