d100f77b9c
This change includes logic to resolve dependencies declared by stacks. The design is described in https://github.com/marapongo/mu/blob/master/docs/deps.md. In summary, each stack may declare dependencies, which are name/semver pairs. A new structure has been introduced, ast.Ref, to distinguish between ast.Names and dependency names. An ast.Ref includes a protocol, base part, and a name part (the latter being an ast.Name); for example, in "https://hub.mu.com/mu/container/", "https://" is the protocol, "hub.mu.com/" is the base, and "mu/container" is the name. This is used to resolve URL-like names to package manager-like artifacts. The dependency resolution phase happens after parsing, but before semantic analysis. This is because dependencies are "source-like" in that we must load and parse all dependency metadata files. We stick the full transitive closure of dependencies into a map attached to the compiler to avoid loading dependencies multiple times. Note that, although dependencies prohibit cycles, this forms a DAG, meaning multiple inbound edges to a single stack may come from multiple places. From there, we rely on ordinary visitation to deal with dependencies further. This includes inserting symbol entries into the symbol table, mapping names to the loaded stacks, during the first phase of binding so that they may be found subsequently when typechecking during the second phase and beyond. |
||
---|---|---|
.. | ||
backend.go | ||
context.go | ||
phase.go | ||
visitor.go |