Module resolver 

Name resolution (spec §5.1, v0.1 §4.1, v0.2 §4.1).

Builds symbol tables for the commons and validates that:

• No two top-level items share a name (types, fns, methods are all named).
• Every TypeRef::Named resolves to a declared type.
• Every free function call resolves to a function declaration.
• Every identifier in expression position resolves to a parameter, a let binding, or self (inside a method).
• Constructor / static calls (TypeName.method(args)) resolve either to the built-in T.of of a refined type, a static method on T, or a variant constructor when T is a sum type.
• Record construction targets a declared record type and uses only declared fields.
• Method calls resolve via the receiver’s nominal type (the actual type check happens in the type checker).

On success returns a ResolvedCommons — the original AST plus symbol tables the type checker consumes.

Structs

CrossContextCapability

Snapshot of one exported capability in a consumed context, as needed for v0.15 cross-context capability resolution. Operation signatures are expressed in the consumed context’s own namespace (resolved against consumed_types at the call site, mirroring CrossContextService).

CrossContextCapabilityOp

CrossContextInfo

Static information about the consuming context: the set of contexts it consumes, and any aliases introduced via as Alias clauses. Used by the resolver to recognise cross-context service calls and by the checker to type them (v0.6 §4.2).

CrossContextService

Snapshot of one service in a consumed context, as needed for v0.6 cross-context type checking. The params and return type are expressed in the consumed context’s own namespace.

MethodTable

Per-type method table built during resolution: keyed by method name, values are clones of the FnDecl for that method.

ResolvedCommons

Output of resolution: the AST plus the symbol tables the checker needs.

Functions

resolve

Resolve names in a single-file (or already-merged) commons. Use this entry point only for self-contained Bynk programs. For multi-file projects and uses-resolving commons, use resolve_file against a pre-built combined symbol table.

resolve_file

Validate name references inside a single file’s items against an already-built symbol table (resolved.types, resolved.fns, resolved.methods). Used by the project-level driver after combining declarations from every file in a multi-file commons and from every commons brought in by uses.

resolve_file_record

resolve_file, recording binding edges into refs as the walk resolves them (v0.25). The project pass sets the sink’s per-file context; a fresh sink records nothing.