test(install): Verify 2024 edition / resolver=3 doesn't affect resolution
### What does this PR try to resolve?
I was worried there might be bugs related to this. With this out of the way, I think we'll be ready to stabilize `resolver = "3"`.
### How should we test and review this PR?
### Additional information
Fix: trace `config` `[env]` table in dep-info.
### What does this PR try to resolve?
The `env` defined in `config.toml` or `--config env` are stripped before recording in the dep-info file. The absence of the env table doesn't rebuild when env changed
By tracing the `env` table into the `dep-info` file, If the envs changed then the rebuild can be triggered.
Fixes#13280
### How should we test and review this PR?
One commit add the test, the latter commit update the test through the fixes.
### Additional information
The PR only fixed the `env` table changes can't trigger a rebuild, other `CARGO-like` envs
doesn't take into account.
`Registry::describe_source` will be used as default error message, but if the message
come from `Registry::describe_source` is empty, then it uses `SourceId` message
fix(git): dont fetch tags by default
### What does this PR try to resolve?
Change Cargo to pass [`--no-tags`] Git CLI option by default. This aligns with how libgit2 works in Cargo.
Based on the Git official doc,
the flag has been there since at least 2.0.5
[`--no-tags`]: https://git-scm.com/docs/git-fetch/2.0.5#Documentation/git-fetch.txt---no-tags
### How should we test and review this PR?
Not sure if we want a test for this.
`CARGO_NET_GIT_FETCH_WITH_CLI` is barely tested.
### Additional information
Fixes#14687
Support package selection options like `--exclude` in `cargo publish`
Fixes#14652.
Is there a way to make the help text depend on whether nightly/unstable features are enabled? I couldn't find one...
Fix panic when running cargo tree on a package with a cross compiled bindep
### What does this PR try to resolve?
This is an attempt to close out `@rukai's` [PR](https://github.com/rust-lang/cargo/pull/13207#issue-2056019109) for #12358 and #10593 by adjusting the new integration test and resolving merge conflicts.
I have also separated the changes into atomic commits as per [previous review](https://github.com/rust-lang/cargo/pull/13207#discussion_r1543447659).
### How should we test and review this PR?
The integration test that has been edited here is sufficient, plus the new integration test that confirms a more specific case where `cargo tree` throws an error.
### Additional information
I have confirmed the test `artifact_dep_target_specified` fails on master branch and succeeds on this branch.
The first commit fixes the panic and the integration test. Commits 2 and 3 add other tests that confirm behaviour mentioned in related issues.
Commits:
1. [Fix panic when running cargo tree on a package with a cross compiled bindep](5c5ea78ecd) - fixes some panics and changes the integration test to succeed
2. [test: cargo tree panic on artifact dep target deactivated](ed294ab4e7) - adds test to confirm the behaviour for the specific panic from [#10539 (comment)](https://github.com/rust-lang/cargo/issues/10593#issuecomment-1317759526)
initial version of checksum based freshness
Implementation for https://github.com/rust-lang/cargo/issues/14136 and resolves https://github.com/rust-lang/cargo/issues/6529
This PR implements the use of checksums in cargo fingerprints as an alternative to using mtimes. This is most useful on systems with poor mtime implementations.
This has a dependency on https://github.com/rust-lang/rust/pull/126930. It's expected this will increase the time it takes to declare a build to be fresh. Still this loss in performance may be preferable to the issues the ecosystem has had with the use of mtimes for determining freshness.
These tests are modified or renamed to reflect the switch to
checksum fingerprint:
* bust_patched_dep
* modifying_and_moving
* rebuild_on_mid_build_file_modification
* rebuild_sub_package_then_while_package
* skip_mtime_check_in_selected_cargo_home_subdirs
* use_mtime_cache_in_cargo_home
fix: avoid inserting duplicate `dylib_path_envvar` when calling `cargo run` recursively
### What does this PR try to resolve?
If the current program started by `cargo run` recursively call into `cargo run`, the second `cargo run` will insert `search_path` into `dylib_path_envvar` again.
Fixes#14194
### How should we test and review this PR?
The first commit adds the test to reflect the issue. The first call to `cargo run` stores the dylib search path env var to a file. Subsequent calls verify that env var remains the same.
The second commit fixes the behavior by checking if env vars in `search_path` are a prefix of the slice of env vars in `dylib_path_envvar`.
This includes
- `cargo generate-lockfile --ignore-rust-version`
- `cargo update --ignore-rust-version`
This does not include
- `edition = "2024"`
- `resolver = "3"`
fix: Remove implicit feature removal
### What does this PR try to resolve?
Due to problems we ran into with #14016, we're removing implicit features from the 2024 edition to give ourselves more time to design it as we should.
### How should we test and review this PR?
### Additional information
I could have added a new flag for this or made an EditionNext but I decided to remove it in the hopes to avoid any path dependency in solving this the next time.
Due to problems we ran into with #14016, we're removing implicit
features from the 2024 edition to give ourselves more time to design it
as we should.
I could have added a new flag for this or made an EditionNext but I
decided to remove it in the hopes to avoid any path dependency in
solving this the next time.
