### What does this PR try to resolve?
As of #15625, the manifest path argument in `cargo clippy
--manifest-path foo/Cargo.toml --fix` will be ignored. All the workspace
members will be built. The cause is due to the `reload` usage in
`cargo::ops::fix`. We reload the `root_manifest` in the function, which
contains all workspace members.
Will close#15625.
### How to test and review this PR?
The first commit in the PR demonstrates the current problem, and the
second commit corrects it. Use `cargo test --test testsuite
workspaces::fix_only_check_manifest_path_member` to see the test
results.
### What does this PR try to resolve?
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. And that is
why I didn't enable the lint group.
### How to test and review this PR?
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?
Found this as I was preparing for stabilization.
As we create a graph of packages to ensure publish order, a self-cycle
shouldn't matter, so we can skip tracking it.
### How to test and review this PR?
Remap all paths pointing to `build.build-dir`,
i.e., `[BUILD_DIR]/debug/deps/foo-[HASH].dwo` would be remapped to
`/cargo/build-dir/debug/deps/foo-[HASH].dwo`
(note the `/cargo/build-dir` prefix).
This covers scenarios like:
* Build script generated code. For example, a build script may call `file!`
macros, and the associated crate uses [`include!`] to include the expanded
[`file!`] macro in-place via the `OUT_DIR` environment.
* On Linux, `DW_AT_GNU_dwo_name` that contains paths to split debuginfo
files (dwp and dwo).
### 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.
GitHub Actions has Windows SDK pre-installed,
so cdb should be available at that path always.
Additionally, this adds a new CI job for windows-msvc nightly toolchain
### 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
`cargo test` will implicitly build examples as examples binaries
(without --test) by default, when no target selection flags provided.
We don't have test exercising this, so add one.
This test shows the current behavior where cargo add replaces
symlinked Cargo.toml files with regular files. The test passes,
documenting this problematic behavior.
This separates the concern of two different "mode".
- UserIntent: focus on the overall goal of the build
- CompileMode: the actual compile operation for each unit
This is a preparation of adding `-Zno-link`/`-Zlink-only` support,
which we'll have `CompileMode::Link` but that doesn't make sense to
show up in `UserIntent`.
This adds support for the "future" edition which was added to rustc in
https://github.com/rust-lang/rust/pull/137606.
To enable support for unstable editions, this introduces a new
`unstable-editions` cargo feature. The intent is that instead of having
a new feature for each edition that we reuse this feature for all new
editions. I don't see a particular reason we should have a separate one
for each edition, and this helps a bit with scalability and simplifies
some of the edition process.
This also includes a change to rework `supports_compat_lint` explained
in the comment.
### What does this PR try to resolve?
With rust-lang/rust#140035 now merged, we can rely on that rather than
dirty hacks
This is part of #12207
### How should we test and review this PR?
### Additional information
This is meant to fixes#13191
As git sources and registry sources are considered immutable.
I don't think there is any reason excluding those files.
There might be a little chance local Git repositories might have those,
though that is a rare use case.
Alternatively,
we could reject all `.rej`/`.orig` files but `Cargo.toml.orig`.
### What does this PR try to resolve?
`PathSource::list_files` has some heurstic rules for listing files.
Those rules are mainly designed for `cargo package`.
Previously, cargo-vendor relies on those rules to understand what files
to vendor. However, it shouldn't use those rules because:
* Package extracted from a `.crate` tarball isn't Git-controlled, some
rules may apply differently.
* The extracted package already went through `PathSource::list_files`
during packaging. It should be clean enough.
* Should keep crate sources from registry sources in a pristine state,
which is exactly what vendoring is meant for.
Instead, we switch to direct extraction into the vendor directory
to ensure source code is the same as in the `.crate` tarball.
### How should we test and review this PR?
There is already a test `vendor::package_exclude` for the fix of #9054,
though now I think it is not a good fix. The test change shows the
correct behavior change.
I am not sure if we want more tests.
Also, there are some caveats with this fix:
* The overwrite protection in `unpack_package` assumes the unpack
directory is always `<pkg>-<version`>.
We don't want to remove this,
but for cargo-vendor supports vendoring without version suffix.
For that case, we need a temporary staging area,
and move the unpacked source then.
* The heurstic in `PathSource::list_files` did something "good" in
general cases, like excluding hidden directories. That means
common directories like `.github` or `.config` won't be vendored.
After this, those get included. This is another round of churns.
We might want to get other `cargo-vendor` changes along with this
in one single release.
### Additional information
* Fixes#9054
* Fixes#9555
* Fixes#9575
* Fixes#11000
* Fixes#14034
* Fixes#15080
* Fixes#15090
This also opens a door for
* #10310
* #13191
Since we are changing vendored source (again), we might want to remove
the `.rej`/`.orig` special rules in cargo-vendor, as well as look into
the new source-dedup vendor dir layout.
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_SUMMARY_START -->
### Summary Notes
-
[benchmark-result](https://github.com/rust-lang/cargo/pull/15514#issuecomment-2870275766)
by [weihanglo](https://github.com/weihanglo)
Generated by triagebot, see
[help](https://forge.rust-lang.org/triagebot/note.html) for how to add
more
<!--
TRIAGEBOT_SUMMARY_DATA_START$${"entries_by_url":{"https://github.com/rust-lang/cargo/pull/15514#issuecomment-2870275766":{"title":"benchmark-result","comment_url":"https://github.com/rust-lang/cargo/pull/15514#issuecomment-2870275766","author":"weihanglo"}}}$$TRIAGEBOT_SUMMARY_DATA_END
-->
<!-- TRIAGEBOT_SUMMARY_END -->
<!-- TRIAGEBOT_END -->
`PathSource::list_files` has some heurstic rules for listing files.
Those rules are mainly designed for `cargo package`.
Previously, cargo-vendor relies on those rules to understand what
files to vendor. However, it shouldn't use those rules because:
* Package extracted from a `.crate` tarball isn't Git-controlled,
some rules may apply differently.
* The extracted package already went through `PathSource::list_files`
during packaging. It should be clean enough.
* Should keep crate sources from registry sources in a pristine state,
which is exactly what vendoring is meant for.
Instead, we switch to direct extraction into the vendor directory
to ensure source code is the same as in the `.crate` tarball.
There are some caveats:
* The overwrite protection in `unpack_package` assumes the unpack
directory is always `<pkg>-<version`>.
We don't want to remove this,
but for cargo-vendor supports vendoring without version suffix.
For that case, we need a temporary staging area,
and move the unpacked source then.
* The heurstic in `PathSource::list_files` did something "good" in
general cases, like excluding hidden directories. That means
common directorys like `.github` or `.config` won't be vendored.
After this, those get included. This is another round of churns.
We might want to get other `cargo-vendor` changes along with this
in one single release.
### What does this PR try to resolve?
- As issue https://github.com/rust-lang/rust/issues/125246 has already
been fixed, there must be no need for commenting out `--sysroot` anymore
in the tests.
- The bug mentioned in `shared_std_dependency_rebuild()` looks to be
already solved and does not reproduce. So I guess it's safe to
un-comment those lines.
