In 1.71, `.cargo-ok` changed to contain a JSON `{ v: 1 }` to indicate
the version of it. A failure of parsing will result in a heavy-hammer
approach that unpacks the `.crate` file again. This is in response to a
security issue that the unpacking didn't respect umask on Unix systems.
Without this, an attacker can upload globally writable files buried
in the `.crate` file. After a user downloaded and unpacked the file,
the attacker can then write malicous code to the downloaded sources.
test: loose overly matches for git cli output
The output format should be stable I believe, but it turns out not.
This is how `git fetch` man page says [^1]:
```
<flag> <summary> <from> -> <to> [<reason>]
```
In Git 2.41 they've changed the fetch output a bit [^2].
I think let's just loose it to prevent future breakages.
[^1]: https://git-scm.com/docs/git-fetch#_output
[^2]: https://github.blog/2023-06-01-highlights-from-git-2-41/
Consider rust-version when selecting packages for cargo add
When `-Zmsrv-policy` is enabled, try to select dependencies which satisfy the target package's `rust-version` field (if present). If the selected version is not also the latest, emit a warning to the user about this discrepancy.
Dependency versions without a `rust-version` are considered compatible by default.
One remaining question is whether we should go into more detail when explaining the discrepancy and ways to resolve it to the user. For example:
```
warning: selecting older version of `fancy-dep` to satisfy the minimum supported rust version
note: version 0.1.2 of `fancy-dep` has an MSRV of 1.72, which is greater than this package's MSRV of 1.69
```
Implements #10653.
r? `@epage`
When `-Zmsrv-policy` is enabled, try to select dependencies which satisfy the
target package's `rust-version` field (if present). If the selected version is
not also the latest, emit a warning to the user about this discrepancy.
Dependency versions without a `rust-version` are considered compatible by
default.
Implements #10653.
fix(lints): Switch to -Zlints so stable projects can experiment
### What does this PR try to resolve?
In #12115, we explored how we can let stable projects
experiment with `[lints]` to provide feedback. What we settled on is
switching from the `cargo-features` manifest key to the `-Z` flag as
`cargo-features` always requires nightly while `-Z` only requires it
when being passed in. This means a project can have a `[lints]` table
and have CI / contributors run `cargo +nightly check -Zlints` when they
care about warnings.
### How should we test and review this PR?
Demonstrate how you test this change and guide reviewers through your PR.
With a smooth review process, a pull request usually gets reviewed quicker.
If you don't know how to write and run your tests, please read the guide:
https://doc.crates.io/contrib/tests
### Additional information
I considered reworking the code to show the user the errors they would encounter once the feature is stable but held off. I wasn't quite sure what language to use and most likely a user would have something doing error reporting, like CI, so it should be fine.
ci: check if any version bump needed for member crates
### What does this PR try to resolve?
Check if a crate requires a version bump in CI.
Part of #12033
### How should we test and review this PR?
Demo action result: <https://github.com/weihanglo/cargo/actions/runs/4941952784/jobs/8835049007>
### Additional information
This doesn't devalue #12089. I love the changelog detection, saving maintainers' times a lot ( I am the one writing changelogs for each release for now). However, the amount of code there is too excessive to me. I think someday when we are going to integrate [cargo-release](https://crates.io/crates/cargo-release) and/or [ehuss/cargo-new-release](https://github.com/ehuss/cargo-new-release), we can remove this script perhaps entirely :)
I tried to document the script a bit hard. Hope it won't get worse over time.
feat: `lints` feature
### What does this PR try to resolve?
Implement rust-lang/rfcs#3389 which shifts a subset of `.cargo/config.toml` functionality to `Cargo.toml` by adding a `[lints]` table.
This **should** cover all of the user-facing aspects of the RFC
- This doesn't reduce what flags we fingerprint
- This will fail if any lint name as `::` in it. What to do in this case was in the RFC discussion but I couldn't find the thread to see what all was involved in that discussion
- This does not fail if a `[lints]` table is present or malformed unless nightly with the `lints` feature enabled
- The idea is this will act like a `[lints]` table is present in an existing version of rust, ignore it
- The intent is to not force an MSRV bump to use it.
- When disabled, it will be a warning
- When disabled, it will be stripped so we don't publish it
Tracking issue for this is #12115.
### How should we test and review this PR?
1. Look at this commit by commit to see it gradually build up
2. Look through the final set of test cases to make sure everything in the RFC is covered
I tried to write this in a way that will make it easy to strip out the special handling of this unstable feature, both in code and commit history
### Additional information
I'd love to bypass the need for `cargo-features = ["lints"]` so users today can test it on their existing projects but hesitated for now. We can re-evaluate that later.
I broke out the `warn_for_feature` as an experiment towards us systemitizing this stabilization approach which we also used with #9732. This works well when we can ignore the new information which isn't too often but sometimes happens.
This does involve a subtle change to `profile.rustflags` precedence but
its nightly and most likely people won't notice it? The benefit is its
in a location more like the rest of the rustflags.
In rust-lang/cargo#12115, we explored how we can let stable projects
experiment with `[lints]` to provide feedback. What we settled on is
switching from the `cargo-features` manifest key to the `-Z` flag as
`cargo-features` always requires nightly while `-Z` only requires it
when being passed in. This means a project can have a `[lints]` table
and have CI / contributors run `cargo +nightly check -Zlints` when they
care about warnings.
This does involve a subtle change to `profile.rustflags` precedence but
its nightly and most likely people won't notice it? The benefit is its
in a location more like the rest of the rustflags.
The weakening of debuginfo for build script shouldn't turn debuginfo
to `DebugInfo::None`. That will result in not passing `-C debuginfo=0`
to rustc, leading to build artifact cache miss.
bors
Weihang Lo
Deadbeef
Eric Huss
Nilstrieb
Arlo Siemsen
cassaundra
hi-rustin
Ed Page