|
1 | 1 | //! High-level APIs for executing the resolver.
|
2 | 2 | //!
|
3 |
| -//! This module provides functions for running the resolver given a workspace. |
| 3 | +//! This module provides functions for running the resolver given a workspace, including loading |
| 4 | +//! the `Cargo.lock` file and checkinf if it needs updating. |
| 5 | +//! |
4 | 6 | //! There are roughly 3 main functions:
|
5 | 7 | //!
|
6 |
| -//! - `resolve_ws`: A simple, high-level function with no options. |
7 |
| -//! - `resolve_ws_with_opts`: A medium-level function with options like |
| 8 | +//! - [`resolve_ws`]: A simple, high-level function with no options. |
| 9 | +//! - [`resolve_ws_with_opts`]: A medium-level function with options like |
8 | 10 | //! user-provided features. This is the most appropriate function to use in
|
9 | 11 | //! most cases.
|
10 |
| -//! - `resolve_with_previous`: A low-level function for running the resolver, |
| 12 | +//! - [`resolve_with_previous`]: A low-level function for running the resolver, |
11 | 13 | //! providing the most power and flexibility.
|
| 14 | +//! |
| 15 | +//! ### Data Structures |
| 16 | +//! |
| 17 | +//! - [`Workspace`]: |
| 18 | +//! Usually created by [`crate::util::command_prelude::ArgMatchesExt::workspace`] which discovers the root of the |
| 19 | +//! workspace, and loads all the workspace members as a [`Package`] object |
| 20 | +//! - [`Package`] |
| 21 | +//! Corresponds with `Cargo.toml` manifest (deserialized as [`Manifest`]) and its associated files. |
| 22 | +//! - [`Target`]s are crates such as the library, binaries, integration test, or examples. |
| 23 | +//! They are what is actually compiled by `rustc`. |
| 24 | +//! Each `Target` defines a crate root, like `src/lib.rs` or `examples/foo.rs`. |
| 25 | +//! - [`PackageId`] --- A unique identifier for a package. |
| 26 | +//! - [`PackageRegistry`]: |
| 27 | +//! The primary interface for how the dependency |
| 28 | +//! resolver finds packages. It contains the `SourceMap`, and handles things |
| 29 | +//! like the `[patch]` table. The dependency resolver |
| 30 | +//! sends a query to the `PackageRegistry` to "get me all packages that match |
| 31 | +//! this dependency declaration". The `Registry` trait provides a generic interface |
| 32 | +//! to the `PackageRegistry`, but this is only used for providing an alternate |
| 33 | +//! implementation of the `PackageRegistry` for testing. |
| 34 | +//! - [`SourceMap`]: Map of all available sources. |
| 35 | +//! - [`Source`]: An abstraction for something that can fetch packages (a remote |
| 36 | +//! registry, a git repo, the local filesystem, etc.). Check out the [source |
| 37 | +//! implementations] for all the details about registries, indexes, git |
| 38 | +//! dependencies, etc. |
| 39 | +//! * [`SourceId`]: A unique identifier for a source. |
| 40 | +//! - [`Summary`]: A of a [`Manifest`], and is essentially |
| 41 | +//! the information that can be found in a registry index. Queries against the |
| 42 | +//! `PackageRegistry` yields a `Summary`. The resolver uses the summary |
| 43 | +//! information to build the dependency graph. |
| 44 | +//! - [`PackageSet`] --- Contains all of the `Package` objects. This works with the |
| 45 | +//! [`Downloads`] struct to coordinate downloading packages. It has a reference |
| 46 | +//! to the `SourceMap` to get the `Source` objects which tell the `Downloads` |
| 47 | +//! struct which URLs to fetch. |
| 48 | +//! |
| 49 | +//! [`Package`]: crate::core::package |
| 50 | +//! [`Target`]: crate::core::Target |
| 51 | +//! [`Manifest`]: crate::core::Manifest |
| 52 | +//! [`Source`]: crate::core::Source |
| 53 | +//! [`SourceMap`]: crate::core::SourceMap |
| 54 | +//! [`PackageRegistry`]: crate::core::registry::PackageRegistry |
| 55 | +//! [source implementations]: crate::sources |
| 56 | +//! [`Downloads`]: crate::core::package::Downloads |
12 | 57 |
|
13 | 58 | use crate::core::compiler::{CompileKind, RustcTargetData};
|
14 | 59 | use crate::core::registry::{LockedPatchDependency, PackageRegistry};
|
|
0 commit comments