### 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
### 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.
Rather than just builtin codegen backends. This is perma-unstable on the
rustc side, but is useful to enable a codegen backend built separately
from rustc to be used without overwriting RUSTFLAGS as well as to allow
configuring the codegen backend on a per-package basis.
Rather than just builtin codegen backends. This is perma-unstable on the
rustc side, but is useful to enable a codegen backend built separately
from rustc to be used without overwriting RUSTFLAGS as well as to allow
configuring the codegen backend on a per-package basis.
This stabilizes the doctest-xcompile feature by unconditionally enabling
it.
Closes https://github.com/rust-lang/cargo/issues/7040
Closes https://github.com/rust-lang/cargo/issues/12118
## What is being stabilized?
This changes it so that cargo will run doctests when using the
`--target` flag for a target that is not the host. Previously, cargo
would ignore doctests (and show a note if passing `--verbose`).
A wrapper for running the doctest can be specified with the
[`target.*.runner`](https://doc.rust-lang.org/cargo/reference/config.html#targettriplerunner)
configuration option (which is powered by the `--test-runtool` rustdoc
flag). This would typically be something like qemu to run under
emulation. It is my understanding that this should work just like
running other kinds of tests.
Additionally, the
[`target.*.linker`](https://doc.rust-lang.org/cargo/reference/config.html#targettriplelinker)
config option is honored for using a custom linker.
Already stabilized in rustdoc is the ability to [ignore tests
per-target](https://doc.rust-lang.org/nightly/rustdoc/write-documentation/documentation-tests.html#ignoring-targets).
## Motivation
The lack of doctest cross-compile support has always been simply due to
the lack of functionality in rustdoc to support this. Rustdoc gained the
ability to cross-compile doctests some time ago, but there were
additional flags like the test runner that were not stabilized until
just recently.
This is intended to ensure that projects have full test coverage even
when doing cross-compilation. It can be
[surprising](https://github.com/rust-lang/cargo/issues/12118) to some
that this was not happening, particularly since cargo is silent about
it.
## Risks
The cargo team had several conversations about how to roll out this
feature. Ultimately we decided to enable it unconditionally with the
understanding that most projects will probably want to have their
doctests covered, and that any breakage will be a local concern that can
be resolved by either fixing the test or ignoring the target.
Tests in rust-lang/rust run into this issue, [particularly on
android](https://github.com/rust-lang/rust/pull/119147#issuecomment-1863712897),
and those will need to be fixed before this reaches beta. This is
something I am looking into.
Some cross-compiling scenarios may need codegen flags that are not
supported. It's not clear how common this will be, or if ignoring will
be a solution, or how difficult it would be to update rustdoc and cargo
to support these. Additionally, the split between RUSTFLAGS and
RUSTDOCFLAGS can be cumbersome.
## Implementation history
- https://github.com/rust-lang/rust/pull/60387 -- Support added to
rustdoc to support the `--target` flag and runtool and
per-target-ignores.
- https://github.com/rust-lang/cargo/pull/6892 -- Initial support in
cargo.
- https://github.com/rust-lang/cargo/pull/7391 -- Added unstable
documentation.
- https://github.com/rust-lang/cargo/pull/8094 -- Fix target for doc
test cross compilation
- https://github.com/rust-lang/cargo/pull/8358 -- Fixed regression with
`--target=HOST` not working on stable.
- https://github.com/rust-lang/cargo/pull/10132 -- Added note about
doctests not running (under `--verbose`).
- https://github.com/rust-lang/rust/pull/112751 -- Fixed
`--test-run-directory` interaction with `--test-runtool`.
- https://github.com/rust-lang/rust/pull/137096 -- Stabilization (and
rename) of the rustdoc `--test-runtool` and `--test-runtool-arg` CLI
args, and drops `--enable-per-target-ignores` unconditionally enabling
it.
## Test coverage
Cargo tests:
-
[artifact_dep::cross_doctests_works_with_artifacts](56c08f84e2/tests/testsuite/artifact_dep.rs (L1248-L1326))
-- Checks that doctest has access to the artifact dependencies.
-
[build_script::duplicate_script_with_extra_env](56c08f84e2/tests/testsuite/build_script.rs (L5514-L5614))
-- Checks that build-script env and cfg values are correctly handled on
host versus target when cross running doctests.
-
[cross_compile::cross_tests](56c08f84e2/tests/testsuite/cross_compile.rs (L416-L502))
-- Basic test that cross-compiled tests work.
-
[cross_compile::doctest_xcompile_linker](56c08f84e2/tests/testsuite/cross_compile.rs (L1139-L1182))
-- Checks that the linker config argument works.
-
[custom_target::custom_target_minimal](56c08f84e2/tests/testsuite/custom_target.rs (L39-L71))
-- Checks that `.json` targets work with rustdoc cross tests.
-
[test::cargo_test_doctest_xcompile_ignores](56c08f84e2/tests/testsuite/test.rs (L4743-L4777))
-- Checks the `ignore-*` syntax works.
-
[test::cargo_test_doctest_xcompile_runner](2603268cda/tests/testsuite/test.rs (L4783-L4863))
-- Checks runner with cross doctests.
-
[test::cargo_test_doctest_xcompile_no_runner](2603268cda/tests/testsuite/test.rs (L4869-L4907))
-- Checks cross doctests without a runner.
Rustdoc tests:
-
[run-make/doctest-runtool](25cdf1f674/tests/run-make/doctests-runtool)
-- Tests behavior of `--test-run-directory` with relative paths of the
runner.
-
[rustdoc/doctest/doctest-runtool](25cdf1f674/tests/rustdoc/doctest/doctest-runtool.rs)
-- Tests for `--test-runtool` and `--test-runtool-arg`.
## Future concerns
There have been some discussions
(https://github.com/rust-lang/testing-devex-team/issues/5) about
changing how doctests are driven. My understanding is that stabilizing
this should not affect those plans, since if cargo becomes the driver,
it will simply need to build things with `--target` and use the
appropriate runner.
## Change notes
This PR changed tests a little:
- artifact_dep::no_cross_doctests_works_with_artifacts was changed now
that doctests actually work.
- cross_compile::cross_tests was changed to properly check doctests.
- cross_compile::no_cross_doctests dropped since it is no longer
relevant.
- standard_lib::doctest didn't need `-Zdoctest-xcompile` since
`-Zbuild-std` no longer uses a target.
- test::cargo_test_doctest_xcompile was removed since it is a duplicate
of cross_compile::cross_tests
I think this should probably wait until the next release cutoff, moving
this to 1.89 (will update the PR accordingly if that happens).
### What does this PR try to resolve?
Fixes#15006
This changes how cargo-publish works with the unstable
`-Zpackage-workspace` feature.
Before this, when publishing the entire workspace,
like `cargo publish --workspace`,
if there is a package with `package.pulibsh=false,
it'll fail the entire publish process.
After this, when `--workspace` is passed,
or when publishing the virtual workspace,
the intent is more like “publish all publishable in this workspace”,
so skip `publish=false` packages and proceed to publish others.
The new overall behavior looks like this:
* `cargo publish` (inside a `package.publish = false` package): error
* `cargo publish -p publishable -p unpublishable`: error
* `cargo publish --workspace`: skips `package.publish = false
See
https://github.com/rust-lang/cargo/issues/15006#issuecomment-2847660911
### How should we test and review this PR?
* `workspace_flag_with_unpublishable_packages` was added to ensure
`--workspace` work with non-virtual workspace.
* `unpublishable_package_as_versioned_dev_dep` was added to ensure
versioned dev-dependencies won't be skipped and still fail
cargo-publish, as they are required to be published.
There is a new scenario that nothing is going to publish.
I went with a warning instead of hard error because missing publish for
the entire worspace should be a fairly visible. However, this is open
for future to configure via Cargo lint system.
This doesn't need to be an hard error because missing
publish for the entire worspace should be a fairly visible.
However, this is open for future to configure via Cargo lint system.
This changes how cargo-publish works with the unstable
`-Zpackage-workspace` feature.
Before this, when publishing the entire workspace,
like `cargo publish --workspace`,
if there is a package with `package.pulibsh=false,
it'll fail the entire publish process.
After this, when `--workspace` is passed,
or when publishing the virtual workspace,
the intent is more like “publish all publishable in this workspace”,
so skip `publish=false` packages and proceed to publish others.
The new overall behavior looks like this:
- `cargo publish` (inside a `package.publish = false` package): error
- `cargo publish -p publishable -p unpublishable`: error
- `cargo publish --workspace`: skips `package.publish = false
See https://github.com/rust-lang/cargo/issues/15006#issuecomment-2847660911
### What does this PR try to resolve?
This PR implements glob pattern match for known_hosts file. Hosts
written with `*` and `?` now matches correctly.
### Tests
Tests are added accordingly.
### Miscs
This is my first time submitting PR, sorry if there's anything that's
off although I've read the contributor guide.
