Date-unit names (year/month/day/hour/minute/second) as action-local vars are a fatal "already defined in an outer scope" error inside included files

[logbie]

Summary

After #553 (thanks — include from now works for stdlib-heavy libraries!), one more sharp edge: the bare date-unit words year, month, day, hour, minute, second appear to be pre-registered as outer-scope globals. Using any of them as an action-local variable inside an included file is a fatal semantic error:

error[ERROR]: Semantic error in included file 'mod.wfl': Semantic error at line 2, column 5:
Variable 'year' has already been defined in an outer scope. Use 'change year to <value>' to modify it.

The same code in the main file only emits a non-fatal "Could not infer type" warning and runs fine — so the behavior is inconsistent between main and included files.

Environment

• WFL 26.7.4 (main @ b1acf38), Linux release build

Minimal reproduction

mod.wfl:

define action called mk with parameters n:
    store year as n plus 1
    return year
end action

main.wfl:

include from "mod.wfl"
store a as call mk with 1
store b as call mk with 2
display a with "," with b

wfl main.wfl → fatal "Variable 'year' has already been defined in an outer scope."

Scope of the collision

Tested one name at a time as an action-local store inside an included file:

Names	Result
year, month, day, hour, minute, second	❌ fatal "already defined in an outer scope"
id, key, plan, path, basis, total, counter, value, date, time, … everything else I tried	✅ fine

So it's exactly the six singular date-unit words. They're presumably globals backing the date/time API, but they shadow ordinary user variable names, and only fatally so inside includes.

Two things that seem wrong

1. Inconsistency: main-file store year as … is a non-fatal warning and runs; included-file store year as … is fatal. Include and main should behave the same.
2. Surprising reservation: year/day/minute are natural variable names. If they must stay reserved, a clearer message ("year is a reserved date-unit name") would help; ideally an action-local store shadows them like any other local.

Workaround

Rename the local (e.g. year → year_ms). That's what I did in my project, so this isn't blocking me — just reporting the trap and the main-vs-include inconsistency.

Minor adjacent note (not blocking)

expect <expr> to contain "…" prints error[ERROR]: contain assertion requires List or Text type when <expr> is an action's return value, even though the value is Text and the test passes. Happens in both main-file and included-file test suites — looks like the type checker doesn't infer an action's return type for the contain assertion. Non-fatal (tests still pass), just noisy. Happy to file separately if useful.

[logbie]

Assessment: confirmed bug — and I agree it's really two problems.

Verified against main: the six date-unit words are registered as native globals in src/stdlib/time.rs (env.define_native("year", …) … "minute", etc., ~lines 525-533). The redefinition guard "… has already been defined in an outer scope" exists in both src/analyzer/mod.rs:106 and src/interpreter/environment.rs:84. Inside an included file the analyzer path treats store year as … as a fatal outer-scope collision, whereas the main file only emits the non-fatal "could not infer type" warning — that's the inconsistency you saw, and it's genuine.

Fix shape:

1. Make include and main consistent — an action-local store should shadow a stdlib native identically in both paths. The included-file handling in src/analyzer/mod.rs should degrade this to the same warning/shadow behavior as the main file rather than raising a fatal semantic error.
2. If the reservation must stay, emit a targeted message ("year is a reserved date-unit function name") instead of the generic outer-scope error.

The preferred fix only relaxes a current fatal error, so it's backward-compatible. Your adjacent note (expect … to contain complaining when the operand is an action's return value) is the same root cause as #560 (unannotated action return typed as Nothing) — I'd fold it in there rather than file separately. TDD: your mod.wfl/main.wfl pair should run without a fatal error. Already labeled bug; suggest also analyzer.

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

[logbie]

Fixed on branch claude/github-issues-review-i7upri.

Root cause: included files are analyzed with extract_parent_variables, which seeded all global env values as parent "variables" — including the date-unit native functions (year/month/day/hour/minute/second) — so an action-local store year as … fatally conflicted with the builtin's outer-scope binding, while the main-file analyzer (which never has builtins as symbols) only warns and runs.

Fix: extract_parent_variables now skips Value::NativeFunction entries. The analyzer already resolves builtins via is_builtin_function, so seeding them as shadowable variables only made includes stricter. Now the include path matches the main path — an action-local shadows the builtin (non-fatal, just the same "could not infer type" warning you noted as acceptable). Verified across all six words in tests/github_issues_batch_test.rs.

---

Generated by Claude Code

[logbie]

Status: verified merged on main — recommend closing.

Same situation as its siblings: the last note here said "fixed on branch claude/github-issues-review-i7upri", and that branch has since merged — PR #587, commit 2c52826.

Evidence on current main:

• The include-analysis path was the root cause (included files were analyzed with extract_parent_variables, so the six registered date-unit words looked like outer-scope bindings and any action-local reuse became a fatal "already defined in an outer scope"). src/interpreter/mod.rs and src/parser/stmt/route.rs carry the fix in that commit.
• Regression tests in tests/github_issues_batch_test.rs: date_unit_local_in_included_file_not_fatal and all_date_unit_words_usable_as_include_locals — the latter exercises all six words (year, month, day, hour, minute, second) as include-locals, which was your "it's really two problems" second half.
• Green in the Integration Tests job on main.

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

[logbie]

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

Fixed by PR #587 — extract_parent_variables now skips Value::NativeFunction entries, so included files no longer pre-register the date-unit words as fatal outer-scope globals.

Repro from this issue now runs clean:

$ wfl main.wfl
2,3
[exit 0]

The only remaining diagnostics are the expected non-fatal Undefined action 'mk' include-relaxation warnings; the fatal Variable 'year' has already been defined in an outer scope is gone. Closing as completed.

---

Generated by Claude Code