Type resolution infrastructure

[mattrobenolt]

Overview

Enhance the TypeResolver to support more complete type resolution, enabling semantic lint rules that need to understand and compare types.

What it unlocks

• Rule: prefer explicit type annotation with anonymous method calls #21 (prefer explicit type annotation with .init())
• Smarter redundant @as() detection
• Type mismatch warnings
• Detecting when a function returns an unexpected type
• Generic type parameter validation

Current state

TypeResolver.zig already provides:

• resolveNodeType() - resolves AST nodes to TypeInfo
• resolveMethodCall() - finds methods and resolves return types
• findMethodDef() - locates method definitions
• ModuleGraph - tracks modules and their ASTs
• Basic type representations (primitives, user types, std types, pointers, optionals, etc.)

What's missing

1. @This() resolution in return types

   Currently, if a method returns @This(), the resolver returns .unknown. It needs to track the "current container context" during resolution.

   const Foo = struct {
       pub fn init() @This() { ... }  // Should resolve to Foo
   };

2. Type alias following

   Common pattern const Self = @This() is not followed when resolving return types.

   const Foo = struct {
       const Self = @This();
       pub fn init() Self { ... }  // Should resolve to Foo
   };

3. Type equality comparison

   Need to compare if two TypeInfo values represent the same semantic type, accounting for:

   • Direct matches (Foo == Foo)
   • Alias resolution (Self == @This() == containing type)
   • Cross-module types

4. Generic type instantiation tracking

   ArrayList(u8).init() should know it returns ArrayList(u8).

Implementation approach

• Add a container_context field to resolution functions to track the containing type
• Resolve @This() to the container context when available
• Build a symbol table for type aliases within containers
• Implement TypeInfo.semanticEquals() for type comparison

Status

Not yet committed to. Tracking this so rules that need it have a place to point to.

Related

• Control flow analysis infrastructure #18 (control flow analysis) - orthogonal infrastructure
• Rule: prefer explicit type annotation with anonymous method calls #21 (explicit type annotation rule) - would benefit from this