Implement --locked for build-std

[adamgemmell]

What does this PR try to resolve?

This fixes rust-lang/wg-cargo-std-aware#38

How should we test and review this PR?

Drop the version of a dependency in the rust-src Cargo.lock (for example, libc down to 0.2.149). Then build something with build-std.
Before this patch, libc would be silently upgraded to the latest semver-compatible version. Now Cargo will return an error.

Additional information

In order for Cargo to actually attempt to write the std lockfile we need to resolve with optional_deps again. Optional packages aren't actually built.

This works for now but the behaviour will need a rethink for rust-lang/wg-cargo-std-aware#64 - perhaps adding some concept of --locked but only for the std parts of a dependency graph..

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @epage (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[adamgemmell]

r? author

[rustbot]

Failed to set assignee to author: cannot assign: response: {"message":"Not Found","documentation_url":"https://docs.github.com/rest/issues/assignees#add-assignees-to-an-issue","status":"404"}

Note: Only org members with at least the repository "read" role, users with write permissions, or people who have commented on the PR may be assigned.

[weihanglo]

There are already too many fields controlling the locked behavior. Per Ed's suggestion, I'd like to see if we can add one line explaining this field is independent from --locked CLI flag. Perhaps something like:

Suggested change

	/// If `true`, then the resolver will not update the `Cargo.lock` file and
	/// return an error if the lockfile is missing or out of date, similar
	/// to the `GlobalContext::locked()` behaviour. Note that
	/// If `true`, then the resolver will not update the `Cargo.lock` file and
	/// return an error if the lockfile is missing or out of date.
	///
	/// This field is independent from any flags like `--locked` or `--frozen`.
	/// Use [`GlobalContext::locked()`] whenever you have an access to mutable
	/// to [`GlobalContext`], such as at Command arg parsing level.

[weihanglo]

• Lower case for first letter by convention in this repo.
• For rust-src component, it should be conditioned on the availability of rustup. You may use cargo::util::is_rustup to check.

Suggested change

	"Attempted to write to the standard library's lockfile.\n\
	This most likely means the lockfile has been previously modified by mistake.\
	Try removing and readding the `rust-src` component."
	"Attempted to write to the standard library's lockfile at: {}.\n\
	This most likely means the lockfile has been previously modified by mistake.\
	Try removing and readding the `rust-src` rustup component.
	lock_root.as_path_unlocked().join(LOCKFILE_NAME).display(),

[weihanglo]

Why do we remove this? Did it cause any issue?

[weihanglo]

In order for Cargo to actually attempt to write the std lockfile we need to resolve with optional_deps again. Optional packages aren't actually built.

I guess it is for this?

[weihanglo]

cargo/src/cargo/ops/resolve.rs

Lines 289 to 294 in 15fbd2f

	let print = if !ws.is_ephemeral() && ws.require_optional_deps() {
	if !dry_run {
	ops::write_pkg_lockfile(ws, &mut resolve)?
	} else {
	true
	}

Okay it is this one.

I am unsure if removing this is the correct approach. require_optional_deps affects how we resolve dependencies. And with that std starts respecting path override.

cargo/src/cargo/ops/resolve.rs

Lines 163 to 173 in 15fbd2f

	} else if ws.require_optional_deps() {
	// First, resolve the root_package's *listed* dependencies, as well as
	// downloading and updating all remotes and such.
	let resolve = resolve_with_registry(ws, &mut registry, dry_run)?;
	// No need to add patches again, `resolve_with_registry` has done it.
	let add_patches = false;
	// Second, resolve with precisely what we're doing. Filter out
	// transitive dependencies if necessary, specify features, handle
	// overrides, etc.
	add_overrides(&mut registry, ws)?;

[weihanglo]

I am thinking over the UI design of this again. See and discuss in rust-lang/wg-cargo-std-aware#38 (comment).