### What does this PR try to resolve?
At this point it is unlikely for a script to be written for pre-2024
edition and migrated to 2024+ but this code is independent of Editions
so this means we have one less bug and are better prepared for the next
edition.
When we add `cargo fix` support for regular manifest warnings, we'll
need to take into account cargo scripts.
This is a part of #12207.
### How should we test and review this PR?
### Additional information
While looking for where the tests go, I found a couple places with a
hard coded latest-edition in test output and fixed it.
At this point it is unlikely for a script to be written for pre-2024
edition and migrated to 2024+ but this code is independent of Editions
so this means we have one less bug and are better prepared for the next
edition.
When we add `cargo fix` support for regular manifest warnings, we'll
need to take into account cargo scripts.
This is a part of #12207.
### What does this PR try to resolve?
This adds support for cargo script for more cargo commands and is a part
of #12207
Unfortunately, there is a double-warning for unspecified editions for
`cargo remove`. Rather than addressing that here, I'll be noting it in
the tracking issue.
### How should we test and review this PR?
### Additional information
### What does this PR try to resolve?
This PR tries to address this thread
https://github.com/rust-lang/cargo/pull/14649#discussion_r1790468829 in
#14649 regarding `cfg(true)`/`cfg(false)` (and keywords more generally)
which are wrongly accepted[^1] as ident.
To address this, this PR does two things:
1. it introduce a future-incompatibility warning against those (wrongly)
accepted keywords as ident
2. it add parsing for raw-idents (`r#true`) add suggest-it in the
warning
### How should we test and review this PR?
This PR should be reviewed commit-by-commit.
Tests are included in preliminary commits.
### Additional information
I added a new struct for representing `Ident`s which is rawness aware.
Which implied updating `cargo-platform` to `0.2.0` due to the API
changes.
r? @epage
[^1]:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ccfb9c894dbf14e791c8ae7e4798efd0
### What does this PR try to resolve?
Download dependencies first,
So that we can assert the full output of `cargo test` without wildcard.
This regressed since #14850
### How should we test and review this PR?
CI passes.
### What does this PR try to resolve?
This is a regression test to prevent issues like #7416.
The test only run on Linux,
as other platforms have different requirements for PGO,
or emit different PGO function missing warnings.
### How should we test and review this PR?
Not sure how brittle it is. We can optionally run it only on Cargo's CI?
cc #14830
When using `net.git-fetch-with-cli = true` , Cargo fails to clone the
git repository into the cache because `safe.bareRepository` defaults to
`explicit`. This results in an error stating that a bare repository
cannot be used.
This patch sets the `GIT_DIR` environment variable to the correct
repository path instead of removing it. This ensures that Git uses the
correct repository directory and avoids the "cannot use bare repository"
error.
Fixes#14758
When using `net.git-fetch-with-cli = true` , Cargo fails to clone the
git repository into the cache because `safe.bareRepository` defaults
to `explicit`. This results in an error stating that a bare repository
cannot be used.
This patch sets the `GIT_DIR` environment variable to the correct
repository path instead of removing it. This ensures that Git uses the
correct repository directory and avoids the "cannot use bare
repository" error.
Fixes#14758
Signed-off-by: Charalampos Mitrodimas <charmitro@posteo.net>
### What does this PR try to resolve?
Fixes#14735https://github.com/rust-lang/rust/pull/131188 removes libstd.so from
sysroot so `cargo test -Zbuild-std` no longer links to it. That results
in a "Library not loaded: @rpath/libstd-[HASH].dylib" when testing a
proc macro.
This is a pretty niche use case, though it can be easily reproduced by
running `cargo test -Zbuild-std` in any proc-macro package. Like in
[serde-rs/serde](b9dbfcb4ac)
running it would fail.
This patch adds a special case that if it is `cargo run/test` against a
proc-macro, fill in std dynamic library search path for it.
### How should we test and review this PR?
```
CARGO_RUN_BUILD_STD_TESTS=1 cargo +nightly t --test build-std test_proc_macro
```
or
```
git clone https://github.com/serde-rs/serde
cd serde
git switch -d b9dbfcb4ac3b7a663d9efc6eb1387c62302a6fb4
cargo +nightly t --test build-std
```
### Additional information
This is a regression test to prevent issues like #7416.
The test only run on Linux,
as other platforms have different requirements for PGO,
or emit different PGO function missing warnings.
With 2024 stabilized, there will be a "first supported" version which is
above the versions used in tests.
In particular, for the `cargo install` test, we can't test the scenario
until a couple of versions have passed.
We have to rely on Edition 2024 changing ony resolver v3 which is
already covered.
When editing dependencies with cargo, if a relative PathSource is
supplied cargo panics with "both paths are absolute". This is the
opposite of what's actually wrong leading to confusion.
Instead, use the same error formatting we use in other diff_paths calls
and return that error instead of panicking.
When editing dependencies with cargo, if a relative PathSource is
supplied cargo panics with "both paths are absolute". This is the
opposite of what's actually wrong leading to confusion.
This commit changes the error message to say what is actually wrong.
**What does this PR try to resolve?**
Ensures that Cargo first verifies whether a given target supports
building the standard library when the `-Zbuild-std=std` option is
passed to Cargo ([see issue
here](https://github.com/rust-lang/wg-cargo-std-aware/issues/87)). This
information can be obtained by querying `rustc
--print=target-spec-json`. The target spec "metadata" contains an
`Option<bool>` determining whether the target supports building std.
In the case this value is `false`, cargo will stop the build. This
avoids the numerous "use of unstable library" errors, giving a cleaner,
and simpler, "building std is not supported on this target".
**How should we test and review this PR?**
It can be manually tested by running `cargo build --target <target>
-Zbuild-std=std`. If a target who's target-spec marks std as false is
passed, cargo will exit. This works with multiple `--target`'s, and if
any of them don't support std, cargo will exit.
**Additional Information**
This change relies on two things:
* The target-spec metadata in rustc needs to be filled out. Currently,
most fields are None, which is treated as OK with this change. Meaning
this can be merged before the rustc changes.
* The new test case added with this change will fail without at least
`aarch64-unknown-none` having it's target-spec metadata completed.
* Some targets have std support marked as "?". If this state is properly
represented in the target-spec in the future, it needs to be determined
whether this is allowed, so the build can continue, or whether it fails.
### What does this PR try to resolve?
A dry-run release process won't be bumping the versions, making it so it
can't do a dry-run publish because the local/remote registries will
collide. This switches it to give the local registry precedence over the
remote registry to make the dry-run release process work.
Fixes#14789
### How should we test and review this PR?
### Additional information
### What does this PR try to resolve?
This is a follow up to #14846 which changed `run` to return the
`RawOutput`.
Reasons I didn't "update" some code to the new `run` return value
- We were actually using `ProcessBuilder::exec_with_output` and I didn't
want to disentangle what it would take to switch to `Execs`
- We did processing on the `Result` and I didn't want to check how that
could be updated
### How should we test and review this PR?
### Additional information
This is a follow up to #14846 which changed `run` to return the
`RawOutput`.
Reasons I didn't "update" some code to the new `run` return value
- We were actually using `ProcessBuilder::exec_with_output` and I didn't
want to disentangle what it would take to switch to `Execs`
- We did processing on the `Result` and I didn't want to check how that
could be updated
### What does this PR try to resolve?
This unblocks experimenting with having these diverge for #8716
### How should we test and review this PR?
### Additional information
