server/0.6.3 validate_file.das: fopen(NULL) panic when --file is missing; exit 0 + unbalanced env shutdown when --result path can't be opened

[borisbat]

Two small robustness issues in server/0.6.3/validate_file.das error paths (reproduced with daslang 0.6.3):

1. No --file argument → runtime panic instead of a usage error

$ daslang validate_file.das
EXCEPTION: can't fopen NULL name
 at <dasroot>/daslib/fio.das:17:12

config.file defaults to "" and flows straight into fopen. A guard like if (empty(config.file)) { to_log(LOG_ERROR, "--file is required\n"); return; } (or printing usage) would fail cleanly.

2. Unopenable --result path → process still exits 0, and shutdown is skipped

$ daslang validate_file.das -- compiler --file ok.das --result "Z:\no\such\dir\out.json"
unable to open file 'Z:\no\such\dir\out.json'
[daslang atexit] FATAL: g_envTotal=1 at exit (Initialize/Shutdown not balanced)
$ echo $?
0

Two problems here:

• the validator reports success (exit 0) to the language-server client even though no result file was written — main could be declared def main() : int and return non-zero on this path;
• the early-out skips part of the normal teardown, tripping daslang's atexit environment audit (g_envTotal=1). Harmless in practice today, but it means the error path diverges from the normal shutdown path.

Both behaviors are identical on current daslang master and on the 0.6.3-era binary, so this is plugin-side error handling, not a compiler regression. Found while smoke-testing the 0.6.3 server scripts against a daslang work branch — the happy path is fully fine (compiles clean, 0 errors, full token stream).

🤖 Generated with Claude Code