Zero-argument include-exposed action referenced by bare name is fatal at top level & in action bodies (`Variable '<name>' is not defined`) — the call form #580's fix didn't cover

[logbie]

Summary

#580 fixed the <action> of <args> form for include-exposed actions (confirmed working on the build below). But there is a third call form #580's fix did not cover: a zero-argument action referenced by its bare name, e.g. store x as greet where greet comes from an include from file.

Because a bare zero-arg reference parses to Expression::Variable("greet") (there is no FunctionCall/ActionCall node and no of/call keyword), it never reaches the include-aware relaxation that #548/#580 added — so it takes the plain fatal Variable '<name>' is not defined path. It is fatal at top level and inside action bodies, but (like #580's original of symptom) works inside a main loop. call greet and adding a dummy parameter both work.

Environment

• WFL 26.7.21 (WebFirst Language (WFL) version 26.7.21), Linux, release build (cargo build --release)

Minimal reproduction

mod.wfl:

define action called greet:
    return "hello from greet"
end action

main.wfl:

include from "mod.wfl"
store x as greet
display x

wfl main.wfl →

error[ANALYZE-SEMANTIC]: Variable 'greet' is not defined

x never prints; exit 3. The same store x as greet in the same file (no include) prints hello from greet.

The matrix (measured on 26.7.21)

Zero-arg action greet exposed via include from, referenced by bare name:

context	result
top-level statement	❌ fatal Variable 'greet' is not defined (exit 3)
inside a define action body	❌ fatal (exit 3)
inside a main loop	✅ works (hello from greet)
store x as call greet (top level)	✅ works (non-fatal Undefined action warning)
give it a dummy param, store x as greet1 of "x"	✅ works

For contrast, #580's exact of <args> repro now passes on 26.7.21 — both at top level and in an action body:

// mod.wfl:  define action called greet with parameters s:  return "HI-" with s  end action
include from "mod.wfl"
store g as greet of "bob"
display "AFTER=" with g          // AFTER=HI-bob, exit 0

So the of form is fixed; the bare zero-arg form is the surviving variant of the same family (#548 → #580 → this).

Why it survives #580's fix (pointers into current main)

• The include-aware relaxation is warn_undefined_callee_if_includes (src/analyzer/mod.rs:519). Its own doc comment says it is the single method that both the of form (FunctionCall with a bare-Variable callee) and the call … with form (ActionCall) route through — that was #548 fix is incomplete: <action> of <args> to an include-exposed action is still context-dependently fatal (works in main loop/tests, fatal at top level & in action bodies) #580's fix.
• A bare zero-arg reference is neither: it is analyzed by the Expression::Variable branch at src/analyzer/mod.rs:2263, which calls report_undefined_name directly (src/analyzer/mod.rs:2294).
• report_undefined_name (src/analyzer/mod.rs:497) is fatal (errors.push) unless try_depth > 0, and it does not consult has_includes. So the bare-Variable path never gets the relaxation the callee paths now enjoy → fatal. (The main loop cell being non-fatal mirrors #548 fix is incomplete: <action> of <args> to an include-exposed action is still context-dependently fatal (works in main loop/tests, fatal at top level & in action bodies) #580's original context-dependence, so the same context mechanism is presumably at play.)

Suggested fix

When the Expression::Variable branch finds an unresolved name that is not a known variable/parameter/builtin and self.has_includes is true, route it through warn_undefined_callee_if_includes (treat it as a possible zero-arg include-exposed action call) instead of the fatal report_undefined_name. That makes the bare zero-arg form behave like the of and call forms already do under include from, and removes the top-level vs main loop inconsistency.

Workarounds

Any of: call it with call greet; give every shared action a dummy parameter and call it with of (e.g. build_shared of "x"); or keep zero-arg helpers in the same file that uses them.

Impact / context

Found while building the WFL website (wfl-web — the site is written in WFL, rendered with the Scribe templating engine, and served either statically or by WFL's own web server). To share the page model across files, every shared action in lib/site.wfl / lib/playground.wfl had to take a throwaway argument purely so it could be called across an include from — e.g. build_shared of "x" where build_shared needs no input. Minor, with easy workarounds, but it's a small "nothing to unlearn" wrinkle in the module surface now that #580 has smoothed the of form.

[logbie]

Assessment: confirmed bug — the surviving third call form of the #548 → #580 include-resolution family. Your root-cause analysis and suggested fix are correct.

Verified against current main (516c5091, v26.7.21):

• report_undefined_name (src/analyzer/mod.rs:497) is fatal (self.errors.push) unless try_depth > 0, and it does not consult has_includes — exactly as you state.
• The include-aware relaxation warn_undefined_callee_if_includes (src/analyzer/mod.rs:519) is the single method the of form (FunctionCall with a bare-Variable callee) and the call … with form (ActionCall) route through — its own doc comment names #548 fix is incomplete: <action> of <args> to an include-exposed action is still context-dependently fatal (works in main loop/tests, fatal at top level & in action bodies) #580 as the reason they were unified.
• The Expression::Variable branch (src/analyzer/mod.rs:2262) calls report_undefined_name directly at :2294 once the name isn't a parameter / count / builtin / container-property / resolved symbol. So a bare zero-arg reference (store x as greet) never reaches the include relaxation and takes the plain fatal path. Confirmed.

So this is a genuine, distinct variant: greet of "x" and call greet are covered, but bare greet is not, because it lowers to Expression::Variable("greet") with no call node to intercept.

Fix shape: your suggestion is the right one and is backward-compatible (it only relaxes a currently-fatal error, so nothing in TestPrograms/ regresses). In the Expression::Variable branch, when the name is unresolved and not a variable/parameter/builtin/container-property and self.has_includes is true, route it through warn_undefined_callee_if_includes instead of report_undefined_name. Because that helper returns false when there are no includes, ordinary typos in non-include programs stay fatal — the important guardrail to keep. Worth adding a TestPrograms/-style, full-pipeline regression (a mod.wfl zero-arg action + a main.wfl bare reference at top level and inside a define action body), since the existing include tests are of/call-form only, which is why this slipped through.

One note on the main loop cell being non-fatal: that mirrors #580's original context-dependence and is the same mechanism (the callee/relaxation path is reachable there), so the single-point fix above should also remove the top-level-vs-main loop inconsistency you documented.

Suggested labels: bug (already applied), analyzer. Cross-ref: #548 → #580 (this is the third form of that family).

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