Migrate remaining type parsing to go/types

[james-w]

Summary

While fixing issues #15, #16, and #17, we successfully migrated getter return type qualification to use go/types instead of string manipulation. However, there are still two other code paths that use brittle string-based type parsing and should be migrated.

Background

PR fixing #15-#17 introduced qualifyTypeExpr() which uses:

• pkg.TypesInfo.TypeOf(expr) to get actual type information
• types.TypeString(typ, qualifier) for proper package qualification
• Handles ALL Go type patterns automatically (functions, arrays, maps, channels, etc.)

This approach is now used for getter return types in matchers, but two other code paths still use string manipulation.

Remaining Type Parsing to Migrate

1. Constructor Parameter Types (analyzeConstructorParams)

Location: cmd/main.go:253

Current approach: Uses printer.Fprint to convert AST to string

Problem: Constructor parameters with complex types (function types, arrays with custom types) won't have nested types qualified correctly.

Example issue:

// Constructor parameter: func(User) error
// Current: Types inside function signature not qualified
// Needed: func(showcase.User) error

Fix needed: Similar to getter return types - extract AST expression and use qualifyTypeExpr.

2. Struct Field Types (collectFields)

Location: cmd/main.go:731

Current approach: Uses printer.Fprint to convert AST to string, then checks if type name is in typeNames map

Problem: Only handles simple custom types. Complex types with nested custom types (like func(User) error or [10]Product) won't have nested types qualified.

Example issue:

type MyStruct struct {
    Callback  func(User) error    // User not qualified
    Items     [10]Product          // Product not qualified  
}

Fix needed: Use qualifyTypeExpr instead of string-based type checking.

Recommendation

Migrate both code paths to use go/types following the pattern established in #15-#17:

1. Update analyzeConstructorParams to preserve AST expressions
2. Update collectFields to preserve AST expressions
3. Use qualifyTypeExpr for type qualification in both
4. Add test cases with function types and array types

Benefits

• Consistent type qualification across all code paths
• Handles all Go type patterns correctly
• Eliminates remaining brittle string parsing
• Future-proof against Go language changes

Related

• Closes qualifyReturnType doesn't handle function types #15 (function types in getters) ✅ Fixed
• Closes qualifyReturnType doesn't handle array types #16 (array types in getters) ✅ Fixed
• Closes Investigate using go/types for robust type parsing instead of string manipulation #17 (use go/types) ✅ Partially fixed (getters only)
• This issue: Complete the migration for constructor params and struct fields