Typealias resolution replaces unrelated generic types

[fabianmuecke]

As discussed here, there's a wider issue with the typealias resolution replacing unrelated types. The second variant of this issue is manifested by replacing the generic type parameters of generic function arguments with the type set to some unrelated typealias of the same name.

Try this self contained example:

typealias Value = String?

// sourcery: DoIt
protocol Foo {
    func foo<Value>(param: Bar<Value>)
}

struct Bar<Value> {}

using this template:

{% for type in types.protocols where type|annotated:"DoIt" %}
    {% for method in type.methods where method.isGeneric %}
        {{method.parameters.first.typeName}} // "Bar<Value>"
        {{method.parameters.first.typeName.generic.typeParameters.first.typeName}} // "String?", but should be "Value"
    {% endfor %}
{% endfor %}

will output this:

// Generated using Sourcery 2.2.3 — https://github.com/krzysztofzablocki/Sourcery
// DO NOT EDIT

        Bar<Value> // "Bar<Value>"
        String? // "String?", but should be "Value"

[art-divin]

👋🏻 Thank you for your bug report, @fabianmuecke .

I have looked into it, and it seems like there is a missing parsing of GenericParameterListSyntax when Method is instantiated, as opposed to GenericWhereClauseSyntax which is serialized.

Trying things here and there, might be solvable.

[art-divin]

1327 resolves this

[art-divin]

@fabianmuecke release 2.2.4 includes this.

[fabianmuecke]

@fabianmuecke release 2.2.4 includes this.

Great. Thanks for fixing this so quickly, @art-divin! 🎉 🙏

I can confirm, that the fix resolved the issue for us. 👍