Read a real target spec JSON so we no longer need to hardcode
a target spec JSON here.
Cargo itself should not care about the spec schema.
Let's stop bothering compiler contributors.
### What does this PR try to resolve?
RFC 3841 has merged, and x86_64-apple-darwin will be demoted to tier-2
in 1.90.0. In Cargo we usually run test against tier-1 platforms, so
x86_64-apple-darwin should be removed.
Also, that target platform is often the slowest one in CI, we are happy
to remove it to save us a couple of minutes.
https://rust-lang.github.io/rfcs/3841-demote-x86_64-apple-darwin.html
### How to test and review this PR?
Run `cargo test` locally with cross-compile tests enabled, and no
regression.
RFC 3841 has merged, and x86_64-apple-darwin will be demoted to tier-2
in 1.90.0. In Cargo we usually run test against tier-1 platforms, so
x86_64-apple-darwin should be removed.
Also, that target platform is often the slowest one in CI,
we are happy to remove it to save us a couple of minutes.
https://rust-lang.github.io/rfcs/3841-demote-x86_64-apple-darwin.html
### What does this PR try to resolve?
ref https://github.com/rust-lang/cargo/issues/14834
In this pull request, I moved `IndexPackage` to `cargo-util-schemas` to
enable third-party applications and `cargo-dev-registry` to utilize this
common struct.
For instance, crates.io has its own `IndexPackage` located at
005667f041/crates/crates_io_index/data.rs (L5).
By moving it to `cargo-util-schemas`, we allow different applications to
use this struct more easily.
### How to test and review this PR?
It shouldn't break any tests; it's just a refactoring.
The `[hints]` table in a `Cargo.toml` manifest provides optional
information that Cargo can use for building the package, and will use
even when using the package as a dependency. All hints can be safely
ignored, and Cargo only warns about unknown hints, but does not error.
This allows packages to use hints without depending on new Cargo.
Add a `mostly-unused` hint, which allows a package to hint that most
users of the package will not use most of its items. This is useful for
improving the build performance of crates with large dependencies.
Crates can override this hint using `hint-mostly-unused = false` in
their profile for a dependency.
The rustc `-Zhint-mostly-unused` flag tells rustc that most of a crate
will go unused. This is useful for speeding up compilation of large
dependencies from which you only use a few items. Plumb that option
through as a profile option, to allow specifying it for specific
dependencies:
```toml
[profile.dev.package.huge-mostly-unused-dependency]
hint-mostly-unused = true
```
To enable this feature, pass `-Zprofile-hint-mostly-unused`. However,
since this option is a hint, using it without passing
`-Zprofile-hint-mostly-unused` will only warn and ignore the profile
option. Versions of Cargo prior to the introduction of this feature will
give an "unused manifest key" warning, but will otherwise function
without erroring. This allows using the hint in a crate's `Cargo.toml`
without mandating the use of a newer Cargo to build it.
Add a test verifying that the profile option gets ignored with a warning
without passing `-Zprofile-hint-mostly-unused`, and another test
verifying that it gets handled when passing
`-Zprofile-hint-mostly-unused`.
The `is_false` function already exists in the standard library, as
`Not::not`; use that in `skip_serializing_if` rather than defining an
`is_false` function.
The `clippy::perf` lint group is fairly useful for catching bad
practices that might hurt performance marginally.
This PR fixes most of them except `clippy::large_enum_variant`,
which doesn't feel right at this moment and need more researches.
Anyway, overall this PR should be good.
### What does this PR try to resolve?
Before this some end-to-end tests didn't cover Windows platforms.
After this, we cover windows-msvc for
* End-to-end debugger tests.
* Check path is trimmed with symbol viewers like `strings`.
windows-gnu isn't covered
### How to test and review this PR?
There are things needing attentions:
* This adds a new CI job for window-msvc "nightly" toolchain.
* In 2f923b3ff25f847d we don't check if an executable's availability by
running `<cmd> --version`. Instead, we check the file execute bit.
* Enabled windows-msvc tests rely on the software provided by [GitHub
windows runner
image](e330e24b7e/images/windows/Windows2022-Readme.md)
* Windows SDK which provides cdb and other debugger tools
* `strings` is provided by MinGW.
Not every executable has a `--version` flag.
Let's check the exectuability instead.
Note that on Windows we check if it is file only.
There is a `is_executable` crate on crates.io,
though that still depend on winapi so don't bother using it.
### What does this PR try to resolve?
This PR fixes a bug where `cargo add` breaks symlinks to Cargo.toml
files. Currently, when Cargo.toml is a symlink and `cargo add` is used
to add a dependency, the symlink is replaced with a regular file,
breaking the link to the original target file.
This issue was reported in #15241 where a user who relies on symlinked
Cargo.toml files found that `cargo add` breaks their workflow.
Fixes#15241
### How should we test and review this PR?
I've modified `LocalManifest::write()` to check if the path is a
symlink, and if so, follow it to get the actual target path. This
ensures we write to the actual file rather than replacing the symlink.
I've also added a test in `tests/testsuite/cargo_add/symlink.rs` that:
1. Creates a symlinked Cargo.toml file
2. Runs `cargo add` to add a dependency
3. Verifies the symlink is preserved and the dependency is added to the
target file
I've manually tested this fix and confirmed it works correctly.
- Preserve symlinks when writing files atomically in write_atomic()
- Update test to verify correct symlink preservation behavior
- Apply rustfmt formatting
This fixes the issue where cargo add would replace symlinked Cargo.toml
files with regular files, breaking the symlink to the original target.
Fixes#15241
