Calling an include-exposed action from top level is a fatal 'Undefined action' (works inside main loop / test blocks)

[logbie]

Summary

An action made available via include from can be called from inside a main loop or a describe/test block, but calling it from an ordinary top-level statement (module scope) raises a fatal Undefined action that aborts the whole program before any top-level code runs. The behavior is inconsistent depending on the call-site context.

Environment

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

Reproduction

mod.wfl (no stdlib, pure concatenation so this is isolated from #547):

define action called greet with parameters s:
    return "HI-" with s
end action

main.wfl:

include from "mod.wfl"
display "BEFORE"
store g as call greet with "bob"
display "AFTER=" with g

Run wfl main.wfl:

error[ANALYZE-SEMANTIC]: Undefined action 'greet'

BEFORE is never printed — execution is aborted entirely (exit code 0).

Contrast — the same include works from other contexts

Called from a describe/test block (via wfl --test) or from inside a main loop, the same included action resolves correctly at runtime and returns the right value. In those contexts the analyzer still prints Undefined action, but it is non-fatal and the interpreter finds the action.

So:

Call site	Result
top-level statement	fatal, program aborts, nothing runs
check if block (top level)	fatal
main loop body	works (analyzer warning is non-fatal)
describe/test body	works (analyzer warning is non-fatal)

Expected

Consistent behavior: an include-exposed action should be callable from any context (or, if it genuinely can't be resolved, the error should be reported the same way everywhere — not fatal in one place and a harmless warning in another).

Notes

Likely related to how the semantic analyzer registers include-exposed actions relative to when top-level statements are checked. This is separate from #547 (that one is about stdlib calls inside an included action); this one reproduces with a pure, stdlib-free included action.

[logbie]

Triage: confirmed — consistency bug in how include-exposed actions are (not) seen by the static analyzer.

Root cause is architectural. include from is a runtime statement: the interpreter only registers the included file's define actions into the environment when the include executes (src/interpreter/mod.rs, include arm, step "Execute included file in PARENT scope"). But the driver runs the static analyzer over the main file first — analyzer.analyze_static(&program, file_id) in src/main.rs (~L1103) — and every SemanticError it returns is emitted at Severity::Error (src/analyzer/static_analyzer.rs ~L151), which src/main.rs (~L1109–1117) treats as fatal (process::exit(3)). At analysis time the analyzer has no knowledge of any action that comes from an include, so a call to greet is Undefined action 'greet' → fatal → BEFORE never prints, exactly as you saw.

The context inconsistency comes from where the analyzer looks. Top-level statements (and top-level check if) get their action calls resolved and thus flagged fatally. Calls placed inside main loop/forever loop bodies and describe/test blocks are not surfaced as fatal ANALYZE-SEMANTIC errors — the analyzer's statement traversal doesn't check them the same way (the same class of "the analyzer doesn't descend into these bodies" gap that #468 documents for the unused-variable pass) — so execution proceeds and the interpreter, which does have the include's actions registered by the time the loop/test body runs, resolves them correctly. Hence: fatal from top level, harmless everywhere else.

Verdict: confirmed bug (inconsistent handling), analyzer + include integration. This is separate from #547 (that one is stdlib calls inside an included action) and reproduces with a pure, stdlib-free include, as you noted.

Two fix directions (a maintainer should pick):

1. Make the analyzer include-aware (correct, larger): when the main program contains include from "X", resolve+parse X during static analysis and register its top-level action signatures before checking call sites — mirroring register_action_signature for local actions. This is the same "front-end doesn't parse included files" gap the type checker already flags as a TODO at src/typechecker/mod.rs (~L1965–1967), so fixing both together is natural.
2. Make it consistent (smaller): when an include from is present, don't treat an otherwise-undefined action call as a fatal Severity::Error at top level (downgrade to a warning, matching the loop/test behavior), so the interpreter's runtime resolution is given the same chance everywhere.

Direction 1 is the real fix; direction 2 removes the surprising abort quickly if a full include-aware analysis is too big for now. Either way: failing-test-first (a top-level call to an include-exposed action must run, not exit(3)), plus a TestPrograms/ end-to-end. Suggested labels: analyzer, confirmed.

Note: I couldn't cargo build in the automated sandbox (no Rust toolchain), so this confirms your repro from the source rather than a local rebuild.

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