Type checker: `store x as <action call>` raises ERROR "Could not infer type for variable" whenever the callee's return type is Unknown

[logbie]

Summary

store <var> as <call> emits an ERROR-level Could not infer type for variable '<var>' whenever the called action's return type is statically Unknown — which is the normal case for any action that returns an expression built from its (untyped) parameters. The program runs correctly and exits 0; only the static diagnostic is wrong, and it is very noisy.

This is the same gradual-typing philosophy as #567 (an Unknown value means "statically unknown", not "known incompatible"), but on the VariableDeclaration inference path, which #587 did not touch. It is not limited to list indexing — #567's inventory attributes the Could not infer type cascade to "indexing an untyped parameter", but the reproduction below has no lists or indexing at all.

Environment

• WFL main @ 2c52826 (i.e. after Fix five GitHub issues: string coercion, parameter shadowing, operators, scope, typing #587 / Typechecker: Any/Unknown values from list indexing and untyped parameters rejected by strict ERROR rules (false positives) #567's partial fix), Linux, release build
• rustc 1.94.1, cargo 1.94.1

Minimal reproduction

define action called add_one with parameters n:
    return n plus 1
end action

define action called use_it:
    store x as add_one of 3
    return x
end action

display use_it

Output (the program runs and prints 4):

Type checking warnings:
error[ERROR]: Could not infer type for variable 'x'
  ┌─ repro.wfl:6:5
  │
6 │     store x as add_one of 3
  │     ^ Type error occurred here

4

Exit code: 0 (non-fatal).

Note the severity/header inconsistency too: the block is titled Type checking warnings: but the item is labelled error[ERROR].

Scoping the trigger

Case	RHS	Result
store x as add_one of 3 where add_one returns n plus 1 (untyped param → Unknown return)	Unknown	❌ Could not infer type for variable 'x'
store x as gives_text where gives_text returns "hello" (concrete return type)	Text	✅ no diagnostic
display add_one of 3 — the same call used directly, no store	—	✅ no diagnostic

So the trigger is specifically binding an Unknown-typed call result to a variable with store. Callee-before-caller vs. callee-after-caller makes no difference (both fire).

Root cause

Statement::VariableDeclaration in src/typechecker/mod.rs treats an inferred Type::Unknown as an error:

// src/typechecker/mod.rs (~line 638)
if inferred_type == Type::Unknown && !is_container_property_assignment {
    self.type_error(
        format!("Could not infer type for variable '{name}'"),
        None, None, *_line, *_column,
    );
}

Under gradual typing, Unknown here means "statically unknown", which should bind x as Unknown silently — mirroring #587's own change for #567 ("Referencing a binding with no recorded type now yields Unknown silently instead of raising Cannot determine type of variable"). The VariableDeclaration arm just needs the same treatment: when inferred_type == Type::Unknown, record the variable as Unknown and do not raise a type_error.

Impact

Any action that returns an expression involving its parameters has an Unknown return type, so any caller that does store result as helper of ... gets flagged. In a real program built entirely from small mutually-recursive helpers, this dominates the output: the Scribe templating engine emits 104 of these notes on a fully-correct run (out of 106 total diagnostics), which drowns out anything real. Repro:

define action called wrap with parameters s:
    return "[" with s with "]"
end action
define action called go:
    store a as wrap of "x"      // Unknown return -> flagged
    store b as wrap of a        // flagged
    return b
end action
display go                       // prints [[x]], exit 0

Related

• Typechecker: Any/Unknown values from list indexing and untyped parameters rejected by strict ERROR rules (false positives) #567 (open) — the broader Any/Unknown false-positive issue; its warning inventory lists 11x Could not infer type for variable '...' but attributes it to indexing. Fix five GitHub issues: string coercion, parameter shadowing, operators, scope, typing #587 addressed several of Typechecker: Any/Unknown values from list indexing and untyped parameters rejected by strict ERROR rules (false positives) #567's items and the Cannot determine type of variable message, but this VariableDeclaration-path Could not infer type diagnostic still fires (verified on 2c52826), and it reproduces with no indexing at all.

Suggested fix / test

In the VariableDeclaration arm, drop the type_error when inferred_type == Type::Unknown (bind the symbol as Unknown and continue). A regression test: the minimal repro above should type-check clean and run, printing 4 with no error[ERROR] on stderr.

[logbie]

Assessment: confirmed bug — a gradual-typing false positive on the VariableDeclaration inference path. A correct fix is already in flight (PR #589, CI green).

Verified against current main (02129808, v26.7.19). The offending type_error is still present at src/typechecker/mod.rs:641: the Statement::VariableDeclaration arm treats an inferred Type::Unknown as an error and raises Could not infer type for variable '<name>', gated only by a container-property / known-symbol suppression. Your root-cause analysis is exactly right — this is the same "an Unknown value means statically unknown, not known-incompatible" philosophy as #567/#560/#569, but on the store/binding path that #587 didn't touch. It reproduces with no lists or indexing, so it is genuinely distinct from #567's list-indexing framing.

Module/verdict: src/typechecker/mod.rs, VariableDeclaration arm (~L613–641). Confirmed bug, non-fatal (exit 0) but very noisy — your Scribe figure of 104/106 diagnostics matches the "any action returning an expression over its untyped params has an Unknown return type, so every store result as helper of … gets flagged" mechanism.

Fix status: PR #589 (claude/wfl-issue-588-gilola) does the right thing — it drops the type_error block (and the now-dead container-property/known-symbol suppression), binds the symbol as Unknown and continues, leaving the type-compatibility and symbol-recording paths intact so a more specific type is still recorded when available. It honors TDD with two regression tests in tests/github_issues_batch_test.rs (the minimal add_one repro → prints 4, and the chained Scribe-style wrap helpers → prints [[x]], both asserting no Could not infer type and exit 0). All functional CI is green (Build/Test/Clippy, fmt, Integration ubuntu+windows, Run WFL Programs ubuntu+windows, Database Tests, CodeQL, config-lint, CodeRabbit, claude-review) and it's MERGEABLE. Recommend verify + close once #589 merges.

One residual worth a follow-up (not a blocker): the severity/header inconsistency you noted — the block is titled Type checking warnings: while the item is labelled error[ERROR]. That banner-vs-severity mismatch is orthogonal to this fix and would be a good small standalone issue against the diagnostic-rendering path.

Suggested labels: bug, typechecker, gradual-typing.

Posted by the WFL repo warden (automated triage pass).

[logbie]

Confirmed fixed on main (34512e8, #589). The minimal repro now type-checks clean and prints 4 with no error[ERROR]. Verified end-to-end against the Scribe engine: the Could not infer type for variable count dropped from 104 → 0 on a full render/test run, and the suite stays 32/32 (exit 0). Thanks for the fast turnaround — safe to close from my side.

For the record, one unrelated residual remains on the same run (2 notes, not this issue): Cannot index into Nothing when a self-recursive action's result is indexed — the recursive call's return type infers to Nothing. Minimal repro:

define action called other with parameters n:
    create map m:
        "val" is n
    end map
    return m
end action
define action called p_unary with parameters n:
    check if n is greater than 0:
        store r as p_unary of (n minus 1)
        return other of (r["val"])   // error[ERROR]: Cannot index into Nothing
    end check
    return other of n
end action
display (p_unary of 3)["val"]          // runs fine, exit 0

That's the #560/#567 family (return type of a recursive/cross-action call typed as Nothing). Happy to file it separately if it's not already covered.

---

Generated by Claude Code

[logbie]

Verified fixed on WFL 26.7.36 (fc21f2f, Linux release build) during the #610 Phase 1 open-issue inventory.

Fixed by PR #589 — store x as <expr> now binds silently when the callee's return type is statically Unknown, instead of raising an ERROR-level Could not infer type for variable, consistent with the gradual-typing philosophy of #567.

Repro now runs clean:

$ wfl repro.wfl
4
[exit 0]

No Could not infer type for variable 'x' diagnostic. Closing as completed.

---

Generated by Claude Code