Checking and running

Before you build a native binary you usually check the code, and often run it on the reference interpreter. beansc also exposes each compiler stage so you can see what it produced.

beansc check

Type-checks one file without building anything.

beansc check app.b

• On success it prints <file>: ok.
• On failure it prints errors as file:line:col: error: ... and exits 1.

check accepts --target, --cpu, --features, and --runtime, so you can check that code is valid for a specific target and runtime profile without building. A capability a runtime profile lacks is refused here, at check time, by name. See targets.

beansc run

Checks the file and then runs it on the reference interpreter. No native build happens.

beansc run app.b

Since v0.1.51, the compiler reduces temporary allocations, caches decoded literal values, and visits integer ranges one element at a time. An early break no longer requires a list containing the whole range before the loop starts. run remains the reference interpreter; for execution speed, use a native release build with beansc build --release app.b.

Forward arguments to your program after --:

beansc run app.b -- --verbose input.txt

If the program panics on the interpreter, run exits 3. See Exit codes and troubleshooting.

Inspecting the stages

These commands dump one stage of the compiler. They are for understanding and debugging, not for a normal workflow.

Command	What it prints
beansc lex <file.b>...	The token stream.
beansc parse <file.b>...	The parsed AST.
beansc mir <file.b>	The checked, ownership-planned MIR.
beansc llvm <file.b>	The LLVM IR that native builds use.

beansc parse app.b
beansc mir app.b
beansc llvm app.b

lex and parse take one or more files. mir and llvm take one file.

Compiler stack and source limits

From v0.1.53, compiler commands, including the interpreter and editor servers, run on a guarded 256 MiB stack on the original OS thread. Syntax nesting is limited to 256 levels, and a declaration may have a syntax-tree path of at most 16,384 nodes. Long chains preserve evaluation and floating-point association order. Split larger expressions into intermediate let bindings, or split large else if ladders into functions. Iterative chain representation remains future work.