This adds a file to ignore most formatting commits in `git blame`. These
commits usually are not interesting, and being able to skip them makes
it a little easier to traverse a blame history. This is a feature
natively supported by GitHub automatically to ignore these. When running
locally, you need to first configure git to use it.
I was a little on the fence on which PRs to include here. Many of these
are small and probably not too important. However, instead of trying to
figure out some threshold of "is this large enough", I decided to just
include all of them.
I checked these by visually looking at each commit and briefly checking
that it didn't seem to include any non-formatting changes.
I think it would be nice to try to keep commits a little cleaner in the
future, and avoid merging PRs that have things like this (unless it is
due to a change in rustfmt itself). I admit I don't always enforce it
since it can be a significant drag, though.
### What does this PR try to resolve?
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 (I'd like to
rename it to something else in the future, such as CompileAction)
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`.
### How should we test and review this PR?
It should have no functional change.
### Additional information
### What does this PR try to resolve?
Fixes#15604
rustdoc assumes to add static files only when the
toolchain-shared-resources emit-type is specified, or when no emit-type
is specified.
See
80c34983c6/src/librustdoc/html/render/write_shared.rs (L206-L213)
### How should we test and review this PR?
Not going to write a test because I don't think we want to inspect into
how rustdoc arranges static files.
See #15604 for how to reproduce/test.
### Additional information
cc #15370
### What does this PR try to resolve?
This pulls in the tests from rust-lang/rust#140035 and ensures we pass
them, including switching our parser to be more like the one from
rust-lang/rust#137193.
I've added comments specifying why our test results differ from rustcs.
This is part of #12207
### How should we test and review this PR?
### Additional information
We still have work to do to improve the quality of our error messages
### What does this PR try to resolve?
0.9.0 may look like a downgrade but the maintainer has decided to go
back to `0.x` versions rather than continuing to use pre-release
versions
### How should we test and review this PR?
### Additional information
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 a new `cargo fix -Zfix-edition` permanently unstable flag to
assist with edition migration testing, particularly with crater.
The commits and given documentation should explain how it works, but
there will be forthcoming edition documentation (on the forge) once all
the pieces with crater come together.
This adds the `EditionFixMode` enum to control the behavior of
`cargo fix --edition`. The main intent is to provide a way to force
`cargo fix` to migrate to a specific edition, instead of just going to
the "next".
This will be needed for `-Zfix-edition` in order to force it to use the
"future" edition, which is never the "next" edition.
This requires being able to serialize and deserialize this setting as it
is conveyed through an environment variable to the recursive cargo
invocation.
This factors out the code to reload a workspace since I will be needing
to reuse this elsewhere.
There is some risk with this method not getting updated correctly in the
future as new fields are added to Workspace (and it may be missing some
things now), but that is an issue with the existing code.
### What does this PR try to resolve?
This reduces the build time of `cargo-util-schemas` by disabling the
unused `display` and `parse` features of `toml` (which are enabled by
default).
This is useful as `cargo-util-schemas` is intended to be reused outside
of Cargo.
### How should we test and review this PR?
As I believe these features only *feature-gate* items on `toml` (they do
not affect runtime behavior silently), the CI building successfully
should be enough to make sure this does not break anything. ~If this
does not build, I will try to tend to it today, otherwise feel free to
push to this branch.~
<!--
Thanks for submitting a pull request 🎉! Here are some tips for you:
* If this is your first contribution, read "Cargo Contribution Guide"
first:
https://doc.crates.io/contrib/
* Run `cargo fmt --all` to format your code changes.
* Small commits and pull requests are always preferable and easy to
review.
* If your idea is large and needs feedback from the community, read how:
https://doc.crates.io/contrib/process/#working-on-large-features
* Cargo takes care of compatibility. Read our design principles:
https://doc.crates.io/contrib/design.html
* When changing help text of cargo commands, follow the steps to
generate docs:
https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages
* If your PR is not finished, set it as "draft" PR or add "WIP" in its
title.
* It's ok to use the CI resources to test your PR, but please don't
abuse them.
### What does this PR try to resolve?
Explain the motivation behind this change.
A clear overview along with an in-depth explanation are helpful.
You can use `Fixes #<issue number>` to associate this PR to an existing
issue.
### 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
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
-->
### What does this PR try to resolve?
When Cargo's changelog was moved into the book in #15123, it seems the
extension was left as `.md`, whereas the link should point to the
rendered version, which ends with `.html`.
### How should we test and review this PR?
Following the new link in the README's rendered view and observing that
it does indeed point to the changelog should be enough.
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.
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?
We aren't quite ready for writing lints (waiting on an annotate-snippets
release) but I wanted to start recording some lint ideas I had.
### How should we test and review this PR?
Based on clippy's which I assumed would be a good starting point. There
are more area we'll need to fill out during discussion, like the lint
name, what primary group the lint would be in, etc.
### Additional information
### 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
We could say that we delegate this to rustc but if they add support for
multiple frontmatters, we need to update to be able to know which we
should read, so its better to error on our side.
### What does this PR try to resolve?
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`.
### How should we test and review this PR?
Test updates should be sufficient.
### Additional information
This is a follow-up of #15514
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 -->
Not sure if it is really needed,
though Cargo had better follow what platform support says.
> The behavior on Windows is the same on Windows 10 1607 and higher
> if `FileRenameInfoEx` is supported by the filesystem; otherwise,
> `from` can be anything, but `to` must *not* be a directory.
https://doc.rust-lang.org/1.86.0/src/std/fs.rs.html#2430-2435
`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.
<!--
Thanks for submitting a pull request 🎉! Here are some tips for you:
* If this is your first contribution, read "Cargo Contribution Guide"
first:
https://doc.crates.io/contrib/
* Run `cargo fmt --all` to format your code changes.
* Small commits and pull requests are always preferable and easy to
review.
* If your idea is large and needs feedback from the community, read how:
https://doc.crates.io/contrib/process/#working-on-large-features
* Cargo takes care of compatibility. Read our design principles:
https://doc.crates.io/contrib/design.html
* When changing help text of cargo commands, follow the steps to
generate docs:
https://github.com/rust-lang/cargo/tree/master/src/doc#building-the-man-pages
* If your PR is not finished, set it as "draft" PR or add "WIP" in its
title.
* It's ok to use the CI resources to test your PR, but please don't
abuse them.
### What does this PR try to resolve?
Fix comment for cargo/core/compiler/fingerprint/mod.rs
### 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
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
-->
### 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.
