Add --lockfile-path flag

[Ifropc]

This change implements a new --lockfile-path proposed in #5707 .

Functionality added:

• Add --lockfile-path <PATH> to all commands that support manifest-path with exception of:
  • locate-project (doesn't use lock file)
  • verify-project (is deprecated)
  • read-manifest (doesn't use lock file)
• Behind -Zunstable-options and docs
  • The flag's docs / --help has (unstable) in them
• <PATH> must end with Cargo.lock. If specified path doesn't exist (or parent director(ies), create all the parent directories and the lockfile itself

Implementation TLDR: add requested_lockfile_path into Workspace and set it on workspace(gctx) call (setting from the context)
Update lockfile.lock_root() to respect requested_lockfile_path (if set)
Add test cases covering all affected commands. Tested creating lockfile, reading lockfile, overriding default (./Cargo.lock) lockfile, symlink tests. Extra tests for package to make sure pinned versions from path's lockfile are respected (i.e. double check correct lockfile is used)
I doubt this flag will be used for any command that's not read-only, but I tried to cover all the commands.

[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

[weihanglo]

@rustbot author

[Ifropc]

Thanks for your patience @weihanglo !
@rustbot review

[weihanglo]

Thanks @Ifropc for your patience and contribution!

This is in a good state to merge. It is still unstable so if any bug emerges we can always fix later!

[weihanglo]

@bors r+

[bors]

📌 Commit 04f9e2d has been approved by weihanglo

It is now in the queue for this repository.

[bors]

⌛ Testing commit 04f9e2d with merge 3293d22...

[weihanglo]

@Ifropc

Here are some tasks we can do in follow-ups, if you're still interested :)

#5707 (comment)

For feature gated tests, we should have

• One without -Zunstable-options and fails.
• One with -Zunstable-options but not with masquerade_as_nightly_cargo.

For reference:

cargo/tests/testsuite/build.rs

Lines 298 to 319 in d3e84f0

	fn chdir_gated() {
	let p = project()
	.file("Cargo.toml", &basic_bin_manifest("foo"))
	.build();
	p.cargo("-C foo build")
	.cwd(p.root().parent().unwrap())
	.with_stderr_data(str![[r#"
	[ERROR] the `-C` flag is unstable, pass `-Z unstable-options` on the nightly channel to enable it
	"#]])
	.with_status(101)
	.run();
	// No masquerade should also fail.
	p.cargo("-C foo -Z unstable-options build")
	.cwd(p.root().parent().unwrap())
	.with_stderr_data(str![[r#"
	[ERROR] the `-C` flag is unstable, pass `-Z unstable-options` on the nightly channel to enable it
	"#]])
	.with_status(101)
	.run();
	}

[epage]

If we're going back and making changes, please rename make_execs to something that describes what it does, rather than based on its return type. Personally, I would recommend removing it. It adds an extra layer of indirection (opaqueness) for little benefit.

[bors]

☀️ Test successful - checks-actions
Approved by: weihanglo
Pushing 3293d22 to master...