bug - a local function called inside a lambda emits its unmangled name

[dannymeijer]

Area

Compiler (frontend/backend/codegen)

Summary

A call to a module-level function emits a mangled incan-v1 symbol at a direct call site, but the unmangled source name when the same call appears inside a lambda. The unmangled name does not exist in the generated crate, so the code fails with E0425.

Both call sites below name the same function in the same module. Only the one inside the lambda is emitted wrongly.

Reproduction steps

def cfg_predicate(predicate: &Predicate, snapshot: CfgSnapshot) -> Option[bool]:
    ...


def evaluate(expression: Expression, snapshot: CfgSnapshot) -> Option[bool]:
    if cfg_predicate(predicate, snapshot) == None:          # direct call - emits mangled, resolves
        return None
    return expression.eval((predicate) => cfg_predicate(predicate, snapshot))   # in a lambda - emits bare name

incan oven bake --project .

Output / logs

Generated Rust, direct call — mangled and resolvable:

if __incan_v1_000100000000000000116f76656e5f6c6f63616c5f696e74616b65...(predicate, snapshot.clone())

Generated Rust, same function inside the lambda — bare name, undefined:

let result: Option<bool> = expression
    .eval(|predicate| cfg_predicate(&predicate, snapshot.clone()));

error[E0425]: cannot find function `cfg_predicate` in this scope
    --> src/rust_activation.rs:1080:35

The function itself is emitted correctly under its mangled name elsewhere in the same file, so this is purely the reference inside the lambda body.

Environment

• Compiler built from 0.6.0-dev.4 at 0a8395835, plus the fix on bugfix/1491-rust-struct-variant-patterns
• Stage: emission (symbol projection for identifiers inside lambda bodies)
• Impact: blocking for any module that passes a lambda calling a local function to a Rust method. No source workaround preserves the design: inlining the body into the lambda duplicates logic, and making the function pub does not change the mangling.
• Found in the Incan-authored Oven control plane under workspaces/oven (feature - RFC 119 native Rust facets and direct-rustc planning #1037, PR chore - retain the Incan-authored Oven control plane (#1037) #1487).

[dannymeijer]

Correction: this is a lowering gap, not emission

The description says emission. Tracing it properly, the emitter is behaving correctly and the resolution is lost earlier.

emit_canonical_callee_path (src/backend/ir/emit/expressions/calls.rs) produces the mangled incan-v1 symbol from a canonical_path. Its caller at calls.rs:722 falls back to self.emit_expr(func) when canonical_path is None, and that fallback emits the bare source name. The function itself is emitted correctly under its mangled name in the same file, and the direct call site resolves.

So the defect is that the call node inside a lambda body carries no canonical_path, while the same call in the enclosing scope does. The fix belongs in lowering, where the path is attached, not in the emitter fallback — which is reasonable on its own terms.

Parked here rather than fixed; see #1495 and the RFC 106 discussion for why the ordering changed.

[dannymeijer]

Narrowed the trigger, and it is not what either the issue title or the handover note says. Both corrections matter for where the fix goes.

It is not "emission". The emitter behaves correctly on the facts it is given: emit_call_expr takes the canonical_path branch when the fact is present and falls through to emit_expr when it is absent. The bare name is the absence of a fact, not a wrong choice.

It is also not lambdas in general. I tried four shapes against current 0.6.0-dev.4 and every one resolves correctly:

Shape	Result
lambda bound to a local, then called	resolves
lambda passed to stdlib map_err	resolves
same, capturing an enclosing local	resolves
lambda passed to a user-defined method taking Callable[int, str]	resolves

Each emitted \|code\| __incan_v1_…(code), the same projected identity as the direct call beside it.

The distinguishing condition is that the receiving method is Rust interop. In the real occurrence — rust_activation.incn:198, not native_compilation.incn as the repro implies — Expression comes from from rust::cfg_expr import Expression, Predicate, TargetPredicate at line 9. So expression.eval(...) is a Rust method call, and the lambda is lowered as an argument to a Rust callable, which is a different path from all four above.

That also explains why it shipped: grepping tests/fixtures/valid/ for a fixture that both imports from rust:: and passes a lambda returns nothing. The two files that match on => are match arms, not lambdas. The combination has no coverage at all.

Two consequences for the fix. It belongs on the Rust-interop argument-lowering path rather than in general closure lowering, so the narrow repro is a rust:: import and not a plain def. And because rust-metadata is optional, it needs proving on both the metadata-enhanced path and a default build — a fix that only works with metadata enabled would leave the original bake failing.

Retitling suggestion: a lambda argument to a Rust-interop method loses its callee's canonical path.