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.
feat: lockfile path implies --locked on cargo install
Follow-up of https://github.com/rust-lang/cargo/issues/14421
Resolving one of the items
> cargo install should make --lockfile-path imply --locked
Simply mirrored behavior as if `--locked` was provided (on creating the workspace)
feat(toml): Add `autolib`
### What does this PR try to resolve?
PR #5335 added `autobins`, etc for #5330. Nowhere in there is
discussion of `autolib`.
Cargo script disables support for additional build-targets by disabling
discovery.
Except we don't have a way to disable discovery of `autolib`, leading to #14476.
By adding `autolib`, we can continue in that direction.
This also allows us to bypass inferring of libs on published packages,
like all other build-targets which were handled in #13849.
Fixes#14476
### How should we test and review this PR?
### Additional information
As this seems fairly low controversy, this insta-stabilizes the field.
In prior versions of Cargo, users will get an "unused manifest key"
warning.
For packages where this is set by `cargo publish`, the warning will be suppressed and things will work as normal.
For `cargo vendor`, the same except there will be some churn in the
vendored source as this field will now be set.
For local development, it should be rare to set `autolib` so the lack of
error by discovering a file when this is set shouldn't be a problem.
fix: correct error count for `cargo check --message-format json`
Hi! This is my first time contributing to Cargo. If there is anything that I need to do, please let me know!
(I'm not sure whether the commit message is aligned with the Cargo's convention. If it doesn't, I'm willing to modify it!)
This PR resolves the issue with incorrect error count and ensures warnings are correctly displayed when using `cargo check --message-format json`.
Fixes#14472
rust-lang/rust#122565 adds a new line to thread panic output.
To make the current test suites works on stable, beta, and nightly,
this relaxes the assertion around that by globbing everything.
feat: add CARGO_MANIFEST_PATH env variable
Adds `CARGO_MANIFEST_PATH` variable as part of https://github.com/rust-lang/cargo/issues/12207
Context: `CARGO_MANIFEST_DIR` is not very useful, because there is no `Cargo.toml` file when running a cargo script. In cases when multiple scripts are stored in the same folder, we can't tell which script exactly is being run using `CARGO_MANIFEST_DIR`
