Skip to main content

Module resolver

Module resolver 

Source
Expand description

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.