Type checker: more RHS forms fail inference inside included files — index / object-index / comparison / `length of` (follow-on to #551)

[logbie]

Summary

Follow-on to #551 (fixed in #552, wfl 26.7.2). Builtin calls now infer correctly inside included files — thanks! But several other right-hand-side expression forms still fail type inference when assigned to a variable inside an included file, and each one is fatal:

error[ERROR]: Type error in included file 'mod.wfl': Type error at line N, column 5: Could not infer type for variable 'v'

Environment

• WFL 26.7.2 (main @ 4602406, i.e. after Fix type inference for builtins in included files (issue #551) #552), Linux release build

What still fails vs. what works

Each row is store v as <RHS> inside an action in an included file, called from the main program:

RHS form	Example	Result
builtin call	touppercase of a, substring of a and 0 and 1, wflhash256 of a, parse_json of s	✅ (fixed in #552)
arithmetic	5 plus 3	✅
action-call result	call some_action with a	✅
list index	parts[0] (where parts is string_split of a and "-")	❌
object index	rec["k"] (where rec is parse_json of ...)	❌
comparison result	a is equal to b (also is greater than or equal to, etc.)	❌
length of result	length of a	❌

All four failing forms type-check fine in the main file; only the included-file path can't infer them.

Minimal reproduction

mod.wfl:

define action called f with parameters a and b:
    store parts as string_split of a and "-"
    store v as parts[0]          // ❌ "Could not infer type for variable 'v'"
    return v
end action

main.wfl:

include from "mod.wfl"
store r as call f with "x-y" and "z"
display r

Swap the store v as ... line for store v as a is equal to b, store v as length of a, or (with store rec as parse_json of "{\"k\":1}") store v as rec["k"] to reproduce each variant.

Why it matters

These are bread-and-butter operations — splitting a key and reading parts[1], reading fields off a parsed-JSON object, storing a comparison into a boolean. A real shared library can't avoid them, so include from still isn't usable for a stdlib-heavy module (e.g. a license signer/validator) even after #551. Closing these four RHS forms should make include from fully viable end to end.

Likely cause / suggestion

Same shape as #551: the include type-inference path needs return/result-type handling for IndexExpression (list and map), comparison/BinaryOp boolean results, and the length of operator — mirroring whatever the analyzer/type checker does for these in the main-file path.

Repro test idea

Extend tests/docs_parser_and_include_fixes_test.rs: an included action that does store x as parts[0], store x as rec["k"], store x as a is equal to b, and store x as length of a, each called from the main program, should type-check and run.

[logbie]

First-pass triage (automated warden pass). Verdict: confirmed bug — and a fix is already in flight in #554.

Reproduced the class against the repro: this is the same shape as #551, just wider. The four failing RHS forms in an included action — parts[0] (list index), rec["k"] (object index), a is equal to b (comparison), and length of a — all type-check in the main file but abort fatally on the include path with Could not infer type for variable. Your root-cause read is correct: the type checker (src/typechecker/mod.rs) wasn't pushing a scope for action bodies (so parts wasn't visible when inferring parts[0]), comparisons over Unknown/Any operands inferred Unknown instead of Boolean, indexing an Any collection was rejected outright, and the include pipeline (src/interpreter/mod.rs) surfaced type errors as fatal rather than as non-fatal warnings the way the main-file path does.

#554 addresses all four forms and then some. Its diff touches exactly the predicted spots — typechecker/mod.rs (action-body scope + param symbols, comparison→Boolean, Any indexing→Any), interpreter/mod.rs (include type errors demoted to non-fatal warnings), plus a static_analyzer.rs fix so store-RHS uses inside action/loop bodies aren't ANALYZE-UNUSED false positives. It ships regression tests for each of the four (included_action_can_store_{list_index,object_index,comparison,ordered_comparison,length_of}_result) plus main-file guards and a non-fatal-warning test. Nicely, it closes the class (any future inference gap degrades to a warning) rather than the four instances.

CI on #554 is green: Build/Test/Clippy, fmt, Integration (ubuntu + windows), Run WFL Programs (ubuntu + windows), Database Tests, and CodeQL all pass; only CodeRabbit is still reviewing and Bump Version is (expectedly) skipped. Suggested labels: bug, type-checker, include-system. Next step: let CodeRabbit finish, then review and merge #554 — keep this issue open until then, close as completed on merge.

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