feat: add CARGO_MANIFEST_PATH env variable
Adds `CARGO_MANIFEST_PATH` variable as part of https://github.com/rust-lang/cargo/issues/12207
Context: `CARGO_MANIFEST_DIR` is not very useful, because there is no `Cargo.toml` file when running a cargo script. In cases when multiple scripts are stored in the same folder, we can't tell which script exactly is being run using `CARGO_MANIFEST_DIR`
fix(config): Don't double-warn about `$CARGO_HOME/config`
### What does this PR try to resolve?
The core requirements for this bug are
- You have a `$CARGO_HOME/.config`
- Your project is inside of `$HOME`
We have a check to make sure we don't double-walk `$CARGO/config` but
that check is *after* we warn about there being no `.toml` extension.
To fix this, we just need to move that check outside of the file lookup.
This required changing the `seen` check from checking whether walked the
config file to checking if we've walked the config dir. As we only have
one file per directory, this should work.
Fixes#14560
### How should we test and review this PR?
test commit added the test, fix commit fixed the issue.
### Additional information
The core requirements for this bug are
- You have a `$CARGO_HOME/.config`
- Your project is inside of `$HOME`
We have a check to make sure we don't double-walk `$CARGO/config` but
that check is *after* we warn about there being no `.toml` extension.
To fix this, we just need to move that check outside of the file lookup.
This required changing the `seen` check from checking whether walked the
config file to checking if we've walked the config dir. As we only have
one file per directory, this should work.
Previously `cargo rustc -- <flags>` got a lower precedence than
some of the flags set by cargo internal.
This is a bit unintuitive as Cargo generally treats user-provided
CLI flags with the highest priority.
This commit changes `cargo rustc -- <flags>` to a higher precedence:
higher than most of flags set by Cargo, and only lower than
`build.rustflags` family.
Unsure if this affects people's workflow, so this behavior is only
enabled on nightly for collectin feedback. A environment variable
`__CARGO_RUSTC_ORIG_ARGS_PRIO=1` is provided for users to opt-out.
If everything goes well, the nightly gate will be removed after a
few of releases.
See discussion on https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/rustflags.20precendence.20of.20.60cargo.20rustc.60
feat: make lockfile v4 the default
### What does this PR try to resolve?
This commit makes lockfile version 4 the default version when Cargo
tries to write to a lockfile.
The lockfile version 4 has been stabilized since 1.78.0,
and will become default in 1.83.0.
the length of transition period is pretty similar as before.
One caveat is that in other output from Cargo,
e.g., `cargo metatada`, status messages,
`SourceID` will display in the v4 URL encoded format.
This shouldn't affect the majority of Rust users,
as `SourceId` representation should be opaque to them,
unless comparing `SourceId` across different version of toolchains.
### How should we test and review this PR?
Some of those tests don't really need to be `version = 4`.
They were updated for consistency.
### Additional information
This was discussed in Cargo meeting on 2024-09-24.
This commit makes lockfile version 4 the default version when Cargo
tries to write to a lockfile.
The lockfile version 4 has been stabilized since 1.78.0,
and will become default in 1.83.0.
the length of transition period is pretty similar as before.
One caveat is that in other output from Cargo,
e.g., `cargo metatada`, status messages,
`SourceID` will display in the v4 URL encoded format.
This shouldn't affect the majority of Rust users,
as `SourceId` representation should be opaque to them,
unless comparing `SourceId` across different version of toolchains.
The tests are intended to spot check that shell completions are
registered correctly. That is a low change, low risk area. For shell
integration, we're relying on `clap_complete`s tests.
For our own candidates, we should test the candidate generation
directly, rather than end-to-end.
This reverts parts of commit e7ca9bec80ab5c010c1a84690816da7b64008257, reversing
changes made to bd5f32bb1c7ca273b5d86815bf0ae4adba59ddd8.
Fixes#14545
test: Migrate remaining with_stdout/with_stderr calls
### What does this PR try to resolve?
This is part of #14039 and is another step towards us not needing our own redaction logic.
Along the way, I switched us to using `expect` to make it easier to tell when `allow(deprecated)` should be removed.
### How should we test and review this PR?
### Additional information
Add a `--dry-run` flag to the `install` command
### What does this PR try to resolve?
This PR add the `--dry-run` flag to the `cargo install` command (see #11123).
I've tried to do the bare minimal for this flag to work without changing anything in the output.
In my opinion, the `--dry-run` flag should mimic as close as possible the behavior of the normal command to avoid missing potential issue in the normal execution. ~~Currently we're missing information about where the binary will be installed.~~
Unlike #13598 this PR:
- Include as much of the compilation process as possible without actually compiling
- use the information provided by `BuildContext` instead of `InstallablePackage::new`
- in the same way as `unit_graph`, it add a `dry_run` to the `CompileOptions` and return a `Compilation::new` from the function `compile_ws` without actually compiling.
- keeps the output the same rather than adding status messages indicating which very broad actions would be performed
- ~~remove some warning not relevant in the case of a `--dry-run`~~
Like #13598, the version check and crate downloads still occur.
### How should we test and review this PR?
The first commit include a unit tests to ensure that no binary is actually installed after the dry run.
There is also a snapshot test that show the diff output of the `--help` flag.
### Additional information
Tests and documentation done in #13598, may be cherry picked into this PR if needed.
We do this by resolving for a package version that is compatible
with the most number of MSRVs within a workspace.
If a version requirement is just right, every package will get the
highest MSRV-compatible dependency.
If its too high, packages will get MSRV-incompatible dependency
versions.
This will happen regardless of what we do due to the nature of
`"fallback"`.
If its too low, packages with higher MSRVs will get older-than-necessary
dependency versions.
This is similar to the "some with and without MSRV" workspaces.
When locking dependencies, we do report to users when newer MSRV/SemVer
compatible dependencies are available to help guide them to upgrading if
desired.
Fixes#14414
Disable the shell_completions tests
The shell_completions tests have a few issues that are causing some problems. See https://github.com/rust-lang/cargo/issues/14545 for a description. This disables the tests until those can get resolved.
feat: Add native comlpetion with CompleteEnv under the nightly
### What does this PR try to resolve?
Related issue https://github.com/rust-lang/cargo/issues/6645
Tracking issue https://github.com/rust-lang/cargo/issues/14520
This PR is the first step to move cargo shell completions to native completions by using `clap_complete` crate. It makes users could complete cargo subcommand and flags.
By using `clap_complete` crate, we could extend the supported shells to Bash, Zsh, Elvish, Fish, and PowerShell. However, at the current stage, the support for PowerShell in `clap_complete` is not fully developed.
See https://github.com/clap-rs/clap/issues/3166 to get more context about what features `clap_complete` has supported.
### How to test and review this PR?
1. Build a test environment, including the necessary short completion scripts, and the `complete` function to start an interactive shell with the help of a pty device and obtain completion results.
2. Simply test the completion results of subcommands in bash, zsh, fish, elvish.
fix(new): Add to workspace relative to manifest, not current-dir
### What does this PR try to resolve?
We were correctly doing this for cases like `cargo new foo` or
`cargo new deeper/than/this/directory/foo` but not `cargo new ../foo`.
This came up when discussing #14501
### How should we test and review this PR?
### Additional information
Fix parsing of comma separated values in --crate-type flag
### What does this PR try to resolve?
According to the documentation the `--crate-type` flag accepts a comma separated list of crate types. However, these are never actually split into individual items and passed verbatim to rustc.
Since cargo fails to associate cases such as 'staticlib,cdylib' to a specific crate type internally, it has to invoke rustc to determine the output file types for this unknown crate type, which returns only the first file type of the first crate type in the list. Consequently cargo will be looking only for a single '.a' artifact on Linux to be copied to the target directory.
Fix this by splitting the list of provided crate types into individual items before further processing them.
Fixes#14498
### How should we test and review this PR?
Updated corresponding test cases
### Additional information
fix(toml): Don't require MSRV bump for pub/priv
### What does this PR try to resolve?
In #13308, we decided to make the feature gate for public/private dependencies non-blocking.
Generally, people opt-in to a feature that is non-blocking through `-Z` but some nightly users want an "always on" mode for this, so we offered both in #13340.
In #13340, we made both feature gates work but we did not make them non-blocking for stable, only nightly.
This change makes the feature gate non-blocking on stable.
Unfortunately, this means that 1.83 will be the MSRV for people using public dependencies. Good thing the feature is indefinitely blocked in rustc as that gives us more time.
### How should we test and review this PR?
### Additional information
In #13308, we decided to make the feature gate for public/private
dependencies non-blocking.
Generally, people opt-in to a feature that is non-blocking through `-Z`
but some nightly users want an "always on" mode for this, so we offered
both in #13340.
In #13340, we made both feature gates work but we did not make them
non-blocking for stable, only nightly.
This change makes the feature gate non-blocking on stable.
We were correctly doing this for cases like `cargo new foo` or
`cargo new deeper/than/this/directory/foo` but not `cargo new ../foo`.
This came up when discussing #14501
