Skip to content

Torvik v1.2.1 — Fix to warning system and general patch release

Choose a tag to compare

@torvik-lang torvik-lang released this 14 Jul 14:22
· 118 commits to main since this release
Immutable release. Only release title and notes can be modified.
43b7ba5

A patch release fixing four correctness bugs in v1.2.0. No new features, no breaking
changes for correct programs. Verified by three-generation self-hosting fixpoints and
a 97-case end-to-end suite on Linux and Windows.

Update with:

rune update

Warnings now reach rune run users — and stay visible

Two compounding bugs hid the entire v1.2.0 warnings system from anyone building
through rune (which is to say: almost everyone). rune compiles with -q, and -q
implied --no-warn; and on cached runs no compiler ran at all, so nothing could
print. Both are fixed: warnings are diagnostics, like errors — -q now
suppresses only the informational build chatter — and rune captures the compiler's
diagnostics and replays them on every cached run, until the code is fixed or a
suppressor (--no-warn, !@NO_WARN;, !@ALLOW[...]) is used. The suite now
asserts warnings survive -q builds, so this class can't regress silently.

Unannotated declarations no longer compile silently broken

set v = trim(x); compiled — and v read back as garbage aliasing unrelated
memory. set b = a; segfaulted. Both are now clean located errors pointing at the
fix. The guide has always required type annotations; only the documented
set xs = list_new(); inference may omit one.

Bare statement calls of builtins get a truthful error

trim(s); as a statement claimed "call to undefined function 'trim'" — factually
wrong. It now says what's actually happening: the builtin returns a value, a bare
statement discards it, and here's how to use it.

Diagnostics under apply report your real line numbers

Applied modules are prepended to the compilation unit, so an error on your line 3
was reported as line ~330 of your file. Line numbers past the applied prelude are
now translated back to your file; diagnostics inside an applied module say so
explicitly.

Full Changelog: v1.2.0...v1.2.1