Included files cannot call stdlib functions inside their actions ('X is not a function')

[logbie]

Summary

Any action defined in a file brought in with include from fails to analyze if its body calls a standard-library function (e.g. touppercase, wflhash256, wflhash256_with_salt, parse_json). The analyzer reports '<fn>' is not a function for the included file, drops the action, and every call site then fails with Undefined action '<action>'. The same action works fine when defined in the calling ("main") file.

This effectively makes include from unusable for real shared libraries, since almost any useful module touches the stdlib (crypto, JSON, text helpers, etc.).

Environment

• WFL built from source, .build_meta.json: { "year": 26, "month": 6, "build": 5 }
• Linux, release build (cargo build --release)

Minimal reproduction

mod.wfl:

define action called shout with parameters s:
    return touppercase of s
end action

main.wfl:

include from "mod.wfl"
main loop:
    store g as call shout with "bob"
    display "R=" with g
    break
end loop

Run wfl main.wfl:

error[ERROR]: Undefined action 'shout'
error[ERROR]: Semantic error in included file 'mod.wfl': Semantic error at line 2, column 24: 'touppercase' is not a function

Expected

R=BOB — the included action should be able to call stdlib functions, exactly as it can when defined in the main file.

Control (works)

The identical action defined in the main file works:

store g as touppercase of "bob"
display "R=" with g     // R=BOB

Notes / likely cause

It looks like the semantic analyzer analyzes included files in isolation without the stdlib function registry loaded, so every stdlib call is treated as an undefined function, which then cascades to the action being dropped. Reproduces with touppercase, wflhash256, wflhash256_with_salt, and parse_json; presumably all stdlib functions are affected.

Confirmed from main loop, describe/test blocks, and top-level call sites — all fail the same way. Priming the function at the top level of the main file (store _ as touppercase of "x") before the include does not help.

Impact

Blocks organizing a project into shared modules. Current workaround is to keep every stdlib-using action in the same file that runs it (or concatenate sources at build time), which defeats the purpose of the module system.

[logbie]

Triage: confirmed bug — root cause located in the include path's analyzer setup.

Reproduced by reading the pipeline; the report's diagnosis is essentially correct. When a file is brought in with include from, the interpreter re-runs the whole front-end on the included source (parse → analyze → typecheck) before executing it, at src/interpreter/mod.rs (the include arm, ~L3484–3520). The analyzer for the included file is built with Analyzer::with_parent_variables_mutable(parent_vars), where parent_vars comes from extract_parent_variables(&env) (src/interpreter/mod.rs ~L1409).

The bug: extract_parent_variables iterates every entry in the runtime environment — including the stdlib functions registered into the global env at startup (touppercase, wflhash256, parse_json, …) — and injects each into the child analyzer as a plain SymbolKind::Variable (via infer_type_from_value). So inside the included file, touppercase now resolves to a symbol, but a variable symbol, not a function. analyze_expression's FunctionCall arm (src/analyzer/mod.rs ~L2060–2100) then falls into the _ => branch and pushes 'touppercase' is not a function. That aborts include-time semantic analysis → the define action is never executed → every call site reports Undefined action 'shout'.

Why it works in the main file: the top-level program is analyzed by Analyzer::new() with no parent injection, so touppercase resolves to None, hits the harmless not-found else branch, and is treated as a builtin. The include path is the only one that poisons the scope with function-valued "variables."

Verdict: confirmed bug, analyzer/interpreter (include glue), not the lexer/parser. Backward-compatibility-safe to fix.

Fix shape (minimal, additive): in extract_parent_variables, don't hand function-valued env entries to the child analyzer as variables. Either (a) skip entries whose Value is a native/user function so the builtin-fallback handles them exactly as in the main file, or (b) map them to SymbolKind::Function with the right arity so real call-checking still happens. Option (a) is the smallest correct change and restores main-file parity. TDD: add a failing include test — an included action whose body calls a stdlib function (e.g. touppercase) — asserting it analyzes clean and returns BOB; a good home is tests/ alongside the existing include integration tests, plus a TestPrograms/ end-to-end that must pass with the release build.

Suggested labels: analyzer, interpreter, confirmed. Likely shares a root theme with #548 (the analyzer's limited view of include-exposed symbols).

I could not cargo build in the automated sandbox (no Rust toolchain here), so this is a source-level confirmation of your repro rather than a fresh local rebuild; the fix should still land failing-test-first and run the full pre-merge trio.

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