Skip to content

fix(resolve): rewrite lambda signature types when merging modules - #889

Merged
martian56 merged 1 commit into
mainfrom
agent/fix-lambda-signature-types
Jul 14, 2026
Merged

martian56 merged 1 commit into
mainfrom
agent/fix-lambda-signature-types

Conversation

@martian56

@martian56 martian56 commented Jul 14, 2026 •

Copy link
Copy Markdown
Owner

Problem

A named type used as a closure parameter or return type fails name resolution with cannot find \T` in scopewhen a project is built throughrvpm(package mode), even though the exact same type resolves correctly as a plain function parameter, a return type, or aletannotation. Single-fileraven build` is unaffected.

Because Raven requires closure parameters to be annotated (there is no inference for them), this blocks every higher-order library API expressed over a named type: iterator callbacks, event handlers, ORM row mappers, and so on. A consumer simply cannot write fun(x: SomeType) -> SomeType when building through rvpm.

Minimal reproduction (package mode)

// lib.rv
struct Handler { name: String }
// ...

// lib_test.rv
import "./lib" { Handler }
fun demo() {
    let f = fun(x: Handler) -> Handler = x   // error: cannot find `Handler` in scope
}

let h: Handler = ... and fun helper(h: Handler) in the same file resolve fine; only the closure signature fails.

Root cause

The stdlib expansion pass merges modules and rewrites every type annotation to its mangled, module-qualified name via rewrite_type. rewrite_fn does this for named-function parameter and return types, rewrite_stmt does it for let annotations, and struct/enum/const/impl are all covered. The rewrite_expr ExprKind::Lambda arm rewrote only the lambda body, never its parameter or return type annotations, so those kept the bare name that no longer exists in the merged module scope.

Fix

Rewrite the lambda parameter and return type annotations with the full rename map in the ExprKind::Lambda arm, mirroring rewrite_fn. Value parameters still shadow only globals in the body, so the annotations correctly use the unshadowed map.

Tests

  • New regression test lambda_parameter_type_from_merged_module_resolves in src/resolve/stdlib.rs: a lambda whose parameter and return type come from a merged module now expands, resolves, type-checks, and lowers.
  • Full suite green locally: 685 lib tests plus all integration suites, 0 failures.

Summary by CodeRabbit

  • Bug Fixes
    • Fixed unresolved type references in lambda parameter and return type annotations when modules are merged.
    • Lambda expressions now correctly resolve, type-check, and compile when their annotations refer to types from another module.

@martian56 martian56 self-assigned this Jul 14, 2026
The stdlib rename pass rewrites every type annotation to its merged,
mangled module name so references resolve after packages are combined.
The lambda arm rewrote only the body, leaving parameter and return type
annotations pointing at the bare, now unmapped name. In package mode a
closure whose parameter or return type named a module type then failed
resolution with "cannot find `T` in scope", even though the same type
resolved as a plain parameter, return, or let annotation. Single-file
builds were unaffected because they do not run the merge pass.

Because closure parameters must be annotated, this blocked every
higher-order library API over a named type (iterator callbacks, event
handlers, row mappers). Rewrite the lambda parameter and return type
annotations with the full rename map, exactly as rewrite_fn does for a
named function, and add a regression test covering a lambda whose
parameter and return type come from a merged module.
@martian56
martian56 force-pushed the agent/fix-lambda-signature-types branch from 1b46f70 to 9ee515b Compare July 14, 2026 15:20
Repository owner deleted a comment from coderabbitai Bot Jul 14, 2026
@martian56
martian56 merged commit 46cc564 into main Jul 14, 2026
6 checks passed
@martian56
martian56 deleted the agent/fix-lambda-signature-types branch July 14, 2026 15:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant