Learn

Only what changed

Down to functions

Cargo reruns rustc for whole crates, and rustc reuses its work in groups of functions. blaze's smallest piece of work is a single function.

Inside the running blaze, compiling a function is one small piece of work whose result is remembered, and kept until that function, or something it uses, changes.

Who calls whom

Inside a crate, functions call each other. Here main calls parse and print, and parse calls lex. Tap a function to edit it, and switch between editing its body and changing its signature.

Four functions: main calls parse and print, parse calls lex. A body edit lights only that function; a signature change also lights the functions that call it.

The body is private

A function's body is the code between its braces. Code that calls it relies only on its signature: its name, what it takes and what it gives back.

So when only the body changes, nothing that calls it has to change.

Which functions?

You fix a bug inside the body of lex. Which functions does blaze compile again? Tap each one.

Did anything change that the callers of lex can see?

Show the answer

Only lex. Its signature is the same, so parse calls it exactly as before, and nothing else needs redoing.

Signatures are seen

Change what a function takes or returns, and every caller has to be checked again: code that called it the old way may not fit any more.

Today blaze rechecks more than just the real callers; narrowing it to exactly the callers is planned.

A new parameter

You add a parameter to lex. Which other function now needs a look?

print, because it comes after lex on the screen.Where a function sits doesn't matter, only who calls whom. print never calls lex.
None: only lex changed.That holds for a body edit. A parameter is part of the signature, and callers depend on it.
parse, because it calls lex.parse calls lex the old way, so it has to be checked against the new signature, and you'll likely edit it too.

Show the answer

parse, because it calls lex. parse calls lex the old way, so it has to be checked against the new signature, and you'll likely edit it too.

A few bodies show through

A few exceptions: sometimes callers can see into the body, as with a const fn, an async fn or a function returning impl Trait, a body handed to a macro, or one that declares items. Then a body edit counts as a signature edit.

Patching, not linking

Once the changed functions are compiled, blaze usually doesn't link the program again. It adds the new code at the end of the program file and writes a jump at the start of the old version, so every caller lands in the new code.

The program file as a column of functions. On save, a new lex is written at the end, and the old lex starts with a jump to it.

Even while it runs

A program that links blaze's blaze-live crate takes changed functions while it runs, state intact: about 20 ms from your save, and under a millisecond to swap them in.

Released on macOS on Apple silicon; Linux x86-64 and Windows x86-64 support is on main, for the next release.

What can it take live?

Your game links blaze-live and is running. Which edit can it take without restarting?

A change to how one function works out the height of a jump.That's a body edit: the new function is swapped in while the game keeps running.
A new field on the Player struct.That changes a type. Every Player already in memory has the old shape, so the program has to restart.

Show the answer

A change to how one function works out the height of a jump. That's a body edit: the new function is swapped in while the game keeps running.

Discussion

Questions, corrections, ideas: anything about this page.