You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(resolver): parametric built-in macros with recursive specialization
Rewrite the five built-in macros (or, xor, nand, nor, xnor) with
<W>[W] annotations. The two macros that compose other macros internally
(nor uses or, xnor uses xor) now propagate the parent W through the
inner call site with or inner[W] / xor inner[W] syntax. Existing
scalar callers stay byte-identical via S7.1's default-W-to-1 rule.
Three pieces of new resolver machinery let this happen end to end:
1. Worklist-based specialization. specializeCallSites now iterates a
queue that includes newly-created spec modules, so width bindings
propagate through nested parametric calls of arbitrary depth. The
width-arg resolver looks up parameter references against the
caller spec's bindings, which is what makes `or inner[W]` inside
nor's body bind correctly when nor is specialized at W=8.
2. Alias rewrite on specs. The unresolved_name -> sub_circuit_ref
rewrite the topo loop performs for original files also runs on
freshly-created spec modules, otherwise nested macro call sites
stayed unresolved and tripped E001 (visible on fixtures like
alu_4bit that transitively use xor -> or, nand).
3. ir.Module.source_file_id. Distinguishes "where this module lives
in project.files" (synthetic id for specs) from "what AST it was
resolved from" (the original .circ file). Topology serializer's
import_table lookup and OriginFrame.target_file both follow the
source_file_id, so tooling sees real source paths and the bench
topology hash stays byte-identical to pre-S8 for every fixture.
Bench reports golden matches on all 56 fixtures with zero topology
drift; existing scalar usages expand to the same component graph as
pre-S8 even though they now go through specialization.
0 commit comments