Object Build & Debugging

The object runner exists to answer one question precisely:

Which parts of the compiler can already be lowered to native COFF objects, and where does lowering fail?

Stable strategy

The reliable build strategy is one Semantic unit per child process.

• several units run in parallel;
• each process has a hard timeout;
• a failed unit does not abort the queue;
• successful units persist their .obj files;
• status and logs remain available after the run.

Status phases

Common error families

NATIVE_EXTERNAL_VALUE_UNRESOLVED

Example:

NATIVE_EXTERNAL_VALUE_UNRESOLVED: "m.Rows"

Usually means the source-level selector exists but the native selector cannot map its base value/type/layout safely.

NATIVE_UNRESOLVED_BINDING

Example:

NATIVE_UNRESOLVED_BINDING: "ID"

Often indicates that a transported node retained the field or local name but lost enough context to identify the source binding.

native member ... has no structured layout

The compiler found a member operation but cannot prove a safe field offset for the base type.

UNIMPLEMENTED_NATIVE_GAP

A structural native lowering case is recognized but not yet implemented. This is intentionally explicit.

Debugging by family, not file

A single resolver bug can affect dozens of compiler units. The preferred loop is:

run all units
→ group errors by root cause
→ implement one general fix
→ run all units again
→ compare ready/object counts

This is more valuable than patching individual functions with special cases.

What a useful report contains

• total/ready/failed/timeout counts;
• object count;
• one current error per failed unit;
• worker durations;
• object paths;
• worker logs where needed.

Historical example

An earlier stable report showed 95 total units with 16 ready units and 54 objects. Later resolver work substantially increased object production. Treat these numbers as development snapshots, not compatibility guarantees.