Fast Linker And Developer Build Loop

The fast linker developer loop is the bounded evidence layer for edit-build-run

latency. It covers the current linker and adjacent package, app, and static

site artifact planning paths without running the full release, self-host,

deployment, or hardware matrix.

Run:

make fast-linker-dev-loop-check
make native-linker-check

make native-linker-check depends on make fast-linker-dev-loop-check, so the

native linker gate always validates developer-loop evidence before checking the

native linker toolchain rows.

Evidence Files

• fast-linker/workloads.tsv lists the bounded workloads.
• fast-linker/parallel-stages.tsv lists parallel-safe planning stages.
• fast-linker/incremental-plan.tsv lists reusable metadata keys and link

order state.

• fast-linker/determinism.tsv records deterministic ordering and output hash

requirements.

• fast-linker/diagnostics.tsv defines stable diagnostics.
• perf/fast-linker-developer-loop-benchmarks.tsv records developer-loop

wall-clock and RSS budgets.

• release/fast-linker-workload-report.tsv records measured workload budgets.
• release/fast-linker-incremental-report.tsv records reuse behavior.
• release/fast-linker-determinism-report.tsv records output hashes.
• release/fast-linker-diagnostics-report.tsv records diagnostic stability.
• compat/fast-linker-dev-loop-contract.tsv records release ownership and

stability.

• tools/fast-linker-dev-loop-check.py validates all rows.

Workloads

The gate covers compiler linking, library package metadata, Index packaging,

Kukulkan packaging, and static-site bundle planning. Each workload has a

bounded wall-clock budget and RSS budget. A row fails when evidence is missing,

the budget is exceeded, or an input artifact is not source-owned in this

repository.

Parallel Planning

Object discovery, symbol table construction, relocation planning, archive index

reads, and output writing are described as explicit stages. Stages that run in

parallel must preserve deterministic ordering by sorting object paths, archive

members, symbol names, relocation offsets, or output sections before committing

state. Output writing remains a single-writer stage unless the release evidence

proves byte-identical output across repeated runs.

Incremental Reuse

Incremental planning uses stable hash keys for object metadata, archive symbol

indexes, relocation plans, package manifests, app manifests, and static-site

manifests. A no-change build must reuse all recorded state. A one-object edit,

package edit, app edit, or static-site edit must rebuild only the affected

planning rows and must keep unchanged link order state stable.

Milestone 2 of the optimization roadmap owns the general content-addressed

artifact store. This page records the Milestone 4 linker and developer-loop

requirements that depend on stable hashes today.

Diagnostics

The gate requires stable diagnostics for developer-loop failures:

LINK_DEV_LOOP_BUDGET
LINK_DEV_LOOP_NONDETERMINISTIC
LINK_DEV_LOOP_REUSE
LINK_DEV_LOOP_DUPLICATE_SYMBOL
LINK_DEV_LOOP_SECTION_ORDER
LINK_DEV_LOOP_OUTPUT_HASH

Duplicate symbol diagnostics must name the first object, duplicate object,

symbol, and archive member when present. Diagnostics must remain stable under

parallel planning.

Documentation Impact

Compiler, linker, package-build, app-build, or static-site build changes that

modify developer-loop behavior must update this page, the workload reports, the

compatibility row, and the release notes in the same change.