The workspace behavior doesn't seem to be documented at all, so a blurb
was brought in that is like the profile blurb. The workspace docs then
link out to it so users can be aware of this special workspace behavior.
In a workspace, only the workspace's profile is respected. This is
already documented in the profile documentation but we should raise
visibility of it within the workspace documentation.
In looking over #10625, I remembered we've been having growing pains
with the workspace documentation. It was originally written when there
were a lot fewer workspace features. As more workspace features have
been added, they've been tacked on to the documentation.
This re-thinks the documentation by focusing on the schema, much like
`manifest.md` does.
[Beta] Run `reach_max_unpack_size` test only on debug build
`cargo test --release` fails on test `reach_max_unpack_size` as the binary to exercise is optimized. The alternative approach is removing `cfg!(debug_assertions)` from this line.
<9ef926dafc/src/cargo/sources/registry/mod.rs (L842)>
#11088
[beta] Fix for CVE-2022-36113 and CVE-2022-36114
This PR includes the fixes for CVE-2022-36113 and CVE-2022-36114 targeting the beta branch. See [the advisory](https://blog.rust-lang.org/2022/09/14/cargo-cves.html) for more information about the vulnerabilities.
This gives users of custom registries the same protections, using the
same size limit that crates.io uses.
`LimitErrorReader` code copied from crates.io.
[BETA 1.64] Only override published resolver when the workspace is different
### What does this PR try to resolve?
Ensures when publishing a package that uses an implicit `resolver = "1"` to maintain an MSRV before the `resolver` key was stabilized the implicitness is retained rather than being turned into an explicit setting.
fixes#10954 (assuming that the workspace and its packages are configured with a consistent resolver)
Note: this is a backport of #10961 to beta
Revert "Drop check for mingw32-make."
This reverts 8e35e2f044 which seems to be causing a problem on rust-lang/rust Windows CI. I don't have time to investigate why it is failing right now. The Windows CI runs underneath make itself, so there is some recursive make action going on. However, I can't tell why that would cause failures. Cargo is behaving as-if it is not running underneath make.
I'll try to do some investigation at a later time, for now I'd like to get the update unblocked.
Add reasons to all ignored tests.
This adds a reason string to all `#[ignore]` attributes. This will be displayed when running the test (since 1.61), which can help quickly see and identify why tests are being ignored. It looks roughly like:
```
test basic ... ignored, requires nightly, CARGO_RUN_BUILD_STD_TESTS must be set
test build::simple_terminal_width ... ignored, --diagnostic-width is stabilized in 1.64
test check_cfg::features_with_cargo_check ... ignored, --check-cfg is unstable
test plugins::panic_abort_plugins ... ignored, requires rustc_private
```
Always allow hg to be missing on CI.
`hg` isn't installed on rust-lang/rust Docker images, which causes this check to fail.
Rather than trying to carefully enforce the requirements for `hg` being tested, this just ignores the test if it is unavailable on CI. I think this is something that can be revisited if Cargo ever gains more hg support.
Fix formats_source test requiring rustfmt.
The requirements added in #9892 that `rustfmt` must be present doesn't work in the `rust-lang/rust` environment. There are two issues:
* Cargo is run without using rustup. If you also have rustup installed, the test will fail because the `rustfmt` binary found in `PATH` will fail to choose a toolchain because HOME points to the sandbox home which does not have a rustup configuration.
* rust-lang/rust CI uninstalls rustup, and does not have rustfmt in PATH at all. It is not practical to make rustfmt available there.
The solution here is to just revert the behavior back to where it was where it checks if it can run `rustfmt` in the sandbox. This should work for anyone who has a normal rustup installation (including Cargo's CI). If running the testsuite without rustup, then the test will be skipped.
This also includes a small enhancement to provide better error information when rustfmt fails.
Disable scrape_examples_complex_reverse_dependencies
The test `scrape_examples_complex_reverse_dependencies` no longer works on the latest nightly. It fails with the error:
```
error[E0433]: failed to resolve: could not resolve path `a::f`
--> examples/ex.rs:1:13
|
1 | fn main() { a::f(); }
| ^^^^ could not resolve path `a::f`
|
= note: this error was originally ignored because you are running `rustdoc`
= note: try running again with `rustc` or `cargo check` and you may get a more detailed error
error: Compilation failed, aborting rustdoc
For more information about this error, try `rustc --explain E0433`.
error: could not document `foo`
```
It is not clear to me what this test was trying to exercise, so I'm not sure how to fix it. It has an example that is trying to call a function from a proc-macro, but proc-macros do not export functions.
Disabling for now to get CI passing.
cc `@willcrichton`
Add requirements to cargo_test.
This extends the `#[cargo_test]` attribute to support some additional requirements to control whether or not a test can run. The motivation for this is:
* Can more clearly see when a test is disabled when it prints "ignored"
* Can more easily scan for disabled tests when I do version bumps to see which ones should be enabled on stable (to pass on CI).
The form is a comma separated list of requirements, and if they don't pass the test is ignored. The requirements can be:
* `nightly` — The test only runs on nightly.
* `>=1.55` — The test only runs on rustc with the given version or newer.
* `requires_git` — Requires the given command to be installed. Can be things like `requires_rustfmt` or `requires_hg`, etc.
This also enforces that the author must write a reason why it is ignored (for some of the requirements) so that when I look for tests to update, I know why it is disabled.
This also removes the `CARGO_TEST_DISABLE_GIT_CLI` option, which appears to no longer be necessary since we have migrated to GitHub Actions.
Contrib: Document submodule update process
This adds some contributor documentation on the process I use to update the cargo submodule.
Of course nobody is required to use this process, but I find it works fairly smoothly.
bors
Ed Page
Weihang Lo
Pietro Albini
Weihang Lo
Josh Triplett
Scott Schafer
Wim Looman
Eric Huss
lucas
Yerkebulan Tulibergenov