Module resolve 

The packages a build is made from, and the module names each of them sees.

A package is compiled against its own modules and the public modules of the packages its manifest lists — Imports across a package boundary. This module answers the two questions that has to be settled before any module of any package is compiled:

1. Which packages are in the build, and in what order they can be compiled. resolve walks the manifests from the root package outwards and hands back the set it reached, dependencies first.
2. What each module is called inside the package that imports it. visible_modules builds that one map — the package’s own modules, plus each direct dependency’s public ones under the namespace or, for an unwrapped dependency, under their own names — and reports a name two modules both answer to.

The collision check is here, rather than in the phase that would trip over the ambiguity, because the manifest is what creates it and the manifest is what has to change. A package with no coherent answer for a name is stopped before any of its modules is canonicalized — its files are read and parsed first, since the map is keyed by the names the module headers declare.

What this obtains, and what it does not

A path dependency is read where it lies and compiled from source like any other package. A git dependency is not obtained at all — fetching a source, caching it and recording the result in zelkova.lock is the toolchain appendix’s, and none of it is written yet — so an entry naming one is Error::UnsupportedSource rather than a package quietly missing from the build.

zelkova-core is a dependency of every package and is not written in dependencies; nothing here supplies it, because a compiler that ships its own core has to know where that copy sits and nothing yet says where. What is honoured is the other half of that rule: a package named zelkova-core is seen unwrapped whatever the entry naming it says, so Basics is Basics. What makes Basics.Int the scalar is not that spelling but the package that declares it: scalars knows a scalar by a qualified name that includes CORE_PACKAGE (DEC-15 decision 1).

Structs

DependencyModules

A dependency as the package being compiled sees it: the resolved package, whether this package sees it wrapped, and the modules it offers.

LocalModule

One module the package being compiled declares: the name its header gives it, and the file it was written in as SourceFile::package_path renders it — src/Model.zel.

ModuleOrigin

One entry of the map of names a package can import: which package the module belongs to, what that package calls it, and how it came to be visible here.

ResolvedPackage

One package of the resolved build: its name, the directory holding its zelkova.toml, and that manifest.

Enums

Error

Every way resolving a build, or naming the modules in one, can fail.

OriginKind

How a module came to be visible in the package being compiled, which is the whole of what a collision diagnostic has to say about each of the two modules claiming one name.

Constants

CORE_PACKAGE

The package every other package is seen through, and the one package name the compiler knows on its own.

Functions

resolve

Walk the build’s manifests, starting from the root package, and hand back every package in it — each one after the packages it depends on, so they can be compiled in that order.

test_only_packages

The packages of build that nothing but a test-dependencies entry reaches.

visible_modules

Every module name the package being compiled can import, and what each one names.