Cargo Notes

If the file exists, cargo will use Cargo.lock to decide which dependencies to download and build.
cargo update is effectively equivalent to removing Cargo.lock and then running cargo build if there wasn't a cargo clean in-between. It updates Cargo.lock with more recent compatible versions of packages in the repo.
Cargo uses feature unions if two crates have a dependency on the same version of another crate (including version) and they enable different features (Source1) (Source2).
- By convention, according to Discourse forums and cargo devs, cargo features are supposed to be additive. This has been known to break no_std applications.
- This feature-union convention could be subject to change in the semi-near future? I wonder if the old behavior could also possibly be kept to facilitate dependency reuse/not having multiple versions of the same crate in a library/application...
The same crate with two different versions are not considered the same crate, and trying to use types from one crate in another will error out.
Caret versioning is default in Cargo.toml. See here for more information about what a compatible version means. I.e. if not using Cargo.lock, cargo will check if a newer version exists (both on disk and from the repo) before deciding what version of a crate to (possibly download and) build.
- With caret versioning, it is possible that two crates specifying two different versions of a crate dependency end up both using- and sharing!- a newer third version instead.
- Since cargo works on a DAG, crates whose deps were updated as a result of cargo update (which can happen if their Cargo.tomls use caret versioning) will be rebuilt as well.
If you have a wildcard dependency and a clean build, cargo will use the most up-to-date version from the repository.
- If you change a concrete version of a dependency to a wildcard, and do not clean your dependencies (and delete Cargo.lock), cargo will use the existing crate version on-disk already to satisfy the wildcard, even if its a less recent version. I can't seem to duplicate this. Looks like I forgot to delete Cargo.lock when I observed this behavior? See CargoDump.
cargo doesn't download/build crates if it doesn't have to. This can be demonstrated by taking a repo with dependencies still intact, making a copy of Cargo.lock, running cargo update, cargo build, and then replacing the updated Cargo.lock with the old one.
- Because a binary built with the old Cargo.lock already exists, cargo will simply hard link the binary under target to the existing old binary to "build" it.

Last Updated: 2019-10-30

WDJ

Cargo Notes