Method/Initializer parameter types now resolve to the local type if it exists

[liamnichols]

Background

• Fix associatedtype generics #1345 (comment)

In the latest 2.2.5 release, our templates seemed to have hit a regression where an associated type within an unrelated protocol would show up as the type for a MethodParameter of an unrelated type. This led me to discover a subtle inconsistency between how types of method parameters are resolved compared to variables.

When resolving a variable type from the syntax tree, it will be sure to check for the type name within the containedTypes because this type should take priority over any global type:

Sourcery/SourceryFramework/Sources/Parsing/SwiftSyntax/AST/Variable+SwiftSyntax.swift

Lines 77 to 86 in 070d0b1

	if !isVisitingTypeSourceryProtocol {
	// we are in a custom type, which may contain other types
	// in order to assign correct type to the variable, we need to match
	// all of the contained types against the variable type
	if let matchingContainedType = visitingType?.containedTypes.first(where: {
	$0.localName == typeName?.name
	}) {
	typeName = TypeName(matchingContainedType.name)
	}
	}

This handling was missing for MethodParameter which means that the typeName (and later type) would always be Foo instead of Bar.Foo.

Changes

This change addresses the immediate issue of Method Parameter types not being correct by passing the parent Type into the FunctionParameterSyntax initialiser which is used when walking the syntax tree.

This however isn't quite a complete fix. While looking at the code, I spotted a few other gotchas:

1. Return types also aren't resolved with local nested types in mind
   • I fixed this.. But the same consideration will need to be made for typed throws later on
2. It only works for the immediate parent type and doesn't account for multiple levels of nesting - this flaw also exists with the variable type resolution

But I think that it's a beneficial one for now until some further work can be done to align type resolution. Anyway.. Feedback is welcome 🙏

[art-divin]

👍🏻

[art-divin]

Thank you for leaving NOTE and TODO 👍🏻

[art-divin]

I'll try to release sooner than later, thank you for your contribution 🤝

[liamnichols]

Thanks @art-divin! No rush from my side, we’re fine on 2.2.4 for the time being.

I just felt like I needed to solve the issue for some closure from my debugging session today 😂