Don't downgrade on prerelease `VersionReq` when update with --breaking.
### What does this PR try to resolve?
Do nothing with prerelease when update with `--breaking`.
Fixes https://github.com/rust-lang/cargo/issues/14178
### How should we test and review this PR?
Previous commit add a test, next commit to fix and update.
### Additional information
Revert "fix: Ensure dep/feature activates the dependency on 2024"
### What does this PR try to resolve?
Fixes#14283 by re-opening #14016 so we don't block people testing other Edition 2024 changes.
### How should we test and review this PR?
This reverts commit 99fae9187ac0bae12a03585083169e34dc7a197d.
I initially held off on reverting in case we quickly had a clear direction to go. Since we're still doing some investigation, I decided to move forward with this.
### Additional information
Fixes#14283 by re-opening #14016 so we don't block people testing other
Edition 2024 changes.
This reverts commit 99fae9187ac0bae12a03585083169e34dc7a197d.
Takes local dependencies into account when packaging a workspace. Builds
a temporary package registry to provide local dependencies, and overlays
it on the upstream registry.
This adds `--registry` and `--index` flags to `cargo package`. They act
much like the same arguments to `cargo publish`, except that of course
we are not actually publishing to the specified registry. Instead, these
arguments affect lock-file generation for intra-workspace dependencies:
when simultaneously packaging a crate and one of its dependencies, the
lock-file will be generated under the assumption that the dependency
will be published to the specified registry.
Co-Authored-By: Tor Hovland <55164+torhovland@users.noreply.github.com>
test: Fix some test based on rustc version
### What does this PR try to resolve?
Some test ouput specifies the latest rustc version and will failed when the rustc version get updated
### How should we test and review this PR?
### Additional information
When browsing the docs, I feel like this will make it easier to tell the
role of these traits within the API.
Or in other words, I can easily tell that these fill a support role and
for what, so I know when I care to look into them.
We use this naming pattern for
`cargo_test_support::paths::CargoPathExt`.
fix(test): Move path2url to CargoPathExt::to_url
### What does this PR try to resolve?
This is a small step, like #14243, to improve the clarity of `cargo-test-support`s API.
Overall, I'm trying to make it more obvious on https://docs.rs/cargo-test-support/latest/cargo_test_support/ which items to reach for when. I figured this is one that could be demoted to `paths` When doing so, I noticed `CargoPathExt`. I figured if we had any extension traits for `Path`, then this is a
reasonable one to add.
### How should we test and review this PR?
### Additional information
I was considering moving this into `paths` and noticed `CargoPathExt`.
I figured if we had any extension traits for `Path`, then this is a
reasonable one to add.
Fix passing of links-overrides with target-applies-to-host and an implicit target
### What does this PR try to resolve?
This fixes the link-overrides half of #14195, both the panic, and the fact that the field is being discarded, the latter of which caused the former as discussed in [the issue](https://github.com/rust-lang/cargo/issues/14195#issuecomment-2211481773).
It does so following the blueprint laid out in #13900 - which is also in my opinion the current best summary of the broader context.
### How should we test and review this PR?
For reviewing, comparing to the changes in #13900 might be useful.
### Additional information
I'm pushing a PR for the other half of #14195 simultaneously. I thought it better to keep the PRs small since they're independent, though if merged simultaneously there will be a conflict over the ordering of fields in `Unit`.
test: migrate fetch and list_availables to snapbox
### What does this PR try to resolve?
Part of https://github.com/rust-lang/cargo/issues/14039.
Migrate following to snapbox:
- `tests/testsuite/fetch.rs`
- `tests/testsuite/list_availables.rs`
We now include the prelude in so many places, this simplifies how we can
present how `cargo-test-support` works.
Yes, this included some `use` clean ups but its already painful enough
walking through every test file, I didn't want to do it twice.
test: migrate implicit_features to snapbox
### What does this PR try to resolve?
Part of https://github.com/rust-lang/cargo/issues/14039.
Migrate following to snapbox:
- `tests/testsuite/implicit_features.rs`
test: migrate check_cfg to snapbox
### What does this PR try to resolve?
Part of https://github.com/rust-lang/cargo/issues/14039.
Migrate following to snapbox:
- `tests/testsuite/check_cfg.rs`
---
This commit allow deprecation for most of the tests currently in this file. This is because the tests either use `does_not_contain` or perform multiple `contains` assertion for single tool with macro `x!`.
Here are some potential options to further eliminate the deprecation:
1. Remove the `x!` macro and replace the it with `str![]` for both Windows and non-Windows platforms.
2. Modify the `x!` macro to only generate the `--check-cfg` part for different platforms and manually compose it with `format!`.
I was changing the "duplicate package" warning to be like:
```
[WARNING] skipping duplicate package `a2 v0.5.0 ([ROOT]/foo/b/../a)`:
[ROOT]/foo/b/../a/a2/Cargo.toml
in favor of [ROOT]/foo/a/a2/Cargo.toml
```
and it showed that we were considering two paths to the same package to
be duplicates.
This suppresses that warning.
