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

compute_is_uses_commons_type

Is name a type imported via uses of a commons specifically — the exact predicate ResolvedCommons::is_uses_commons_type caches as uses_commons_type_names, and bynk-emit needs at two real call sites that must never disagree: emit_context_rebrands’s own two steps, “alias the import” and “rebrand the type” (its own doc comment, step 1 “Done in imports”, step 2 the rebrand itself, both in bynk-emit/src/emitter.rs) — an import narrower than the rebrand leaves an undefined name in the generated module; a rebrand narrower than the import leaves an alias imported and never used.

cross_context_service_for

Project one local on call handler into the CrossContextService shape both sides of a cross-context contract check need — a caller resolving a consumed service (crate::symbols::build_cross_context_info) and a callee stamping its own X-Bynk-Contract constant (crate::contract::own_contract_hashes). Sharing this one projection is the whole correctness argument for that symmetry: if the two sides ever diverged, a working deployment would 409 on every call instead of only on real skew. None when sdecl has no on call handler (e.g. an events-only or queue-only service).

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.