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.
This test was ignored in https://github.com/rust-lang/cargo/pull/3189
without much discussion of explaining why.
AFAICT, this test works fine on Windows on both MSVC and GNU.
Empty paths do the expected behavior (preventing cargo from running
rustc). There are some special rules on Windows about discovering the
process to run (such as searching the app's launch directory), but
I do not think that is relevant here. Confirmed by trying to run
`cargo check` in this test fails to find `rustc`.
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.
Contrib: Document new-release process
This adds some contributor documentation on the process I use to bump the version and update the changelog. In case I am unavailable to create the changelog, it may perhaps be useful to someone.
Of course nobody is required to use this process, but I find it works fairly smoothly. However, the tool I use is a hacked together script, and may have some hard-coded things, so it may need some work to be useful to others.
Override to resolver=1 in published package
As discussed in #10112 this avoids inconsistent dependency resolution in development and packaged builds when an edition 2021 crate is published from a workspace using the default resolver=1.
fix(add): Update the lock file
This is done in the command, rather than in the op,
- To consistently construct the `Workspace`
- It is more composable as an API
A downside is we update the git dependencies a second time and any sources we didn't initially update.
Unlike the proposal in the attached issue, this does not roll back on error.
- For some errors, the user might want to debug what went wrong. Losing the intermediate state makes that difficult
- Rollback adds its own complications and risks, including since its
non-atomic
We've already tried to address most potential errors during `cargo add`s processing. To meet this desire, we now error if `--locked` is passed in and we would change the manifest. See that individual commit's message for more details.
Fixes#10901
This is done in the command, rather than in the op,
- To consistently construct the `Workspace`
- It is more composable as an API
A downside is we update the git dependencies a second time.
We are not rolling back on error.
- For some errors, the user might want to debug what went wrong
- Rollback adds its own complications and risks, including since its
non-atomic
Fixes#10901
bors
Eric Huss
binds
lucas
Yerkebulan Tulibergenov
Wim Looman
Ed Page