table, string, math, os, io, coroutine, package and debug name
the runtime's library namespaces. Generated code and the bodies of standard
library modules reach them by those names, so a binding with the same name
does not merely shadow a variable: it hijacks the namespace for everything
compiled after it. On the VM a top-level let table = ... turned a standard
library join into "attempt to call a number value"; on the native backend the
same binding made every array built by a std module come back empty. The
compiler now rejects the binding where it is declared.
let table = mount(UsersTable(page)) // error[TE154]
fn render(string: str) -> str { ... } // error[TE154]Rename the binding. Referencing a module is still fine, since that is a use, not a declaration:
use std::math
let grid = mount(UsersTable(page))
let rounded = math.floor(1.5)The check covers let, var, const, function names and parameters. It is
a stop-gap for a lowering gap: spliced std bodies should not see user
bindings at all, and generated code should reach the libraries through
private aliases. Until that lands, the diagnostic turns a silent miscompile
into a one-line rename.