Weihang Lo [Fri, 19 Aug 2022 22:30:01 +0000 (23:30 +0100)]
Ignore broken but excluded file during traversing
Walkdir's [`filter_entry()`][1] won't call the predicate if the entry
is essentially an `Err` from its underyling `IntoIter`. That means
Cargo hasn't had a chance to call `filter` on an entry that should be
excluded but eventually return an `Err` and cause the loop to stop.
For instance, a broken symlink which should bee excluded by `filter`
will generate an error since `filter` closure is not called with it.
The solution is calling `filter` if an error occurs with a path
(because it has yet been called with that path).
If it's exactly excluded, ignore the error.
bors [Wed, 17 Aug 2022 20:18:30 +0000 (20:18 +0000)]
Auto merge of #11001 - Muscraft:fix-unstable-docs, r=weihanglo
remove missed reference to workspace inheritance in unstable.md
Currently on the nightly docs, workspace inheritance is [under the stable table](https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#workspace-inheritance-1) and the [unstable table](https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#workspace-inheritance). It looks like I forgot to remove it from the unstable table when working on stabilization.
I am not sure if it is worth a beta backport but I will happily open a PR for it if needed.
bors [Tue, 16 Aug 2022 12:29:32 +0000 (12:29 +0000)]
Auto merge of #10975 - theCapypara:flock-enosys-android, r=weihanglo
Fix file locking being not supported on Android raising an error
This PR fixes #10972 by not failing Cargo operations when the `target_os` is Android and file locking is being reported as not being implemented by the kernel.
I am sadly unable to actually test this at the moment, since despite my best efforts I am not able to get Cargo actually cross-compiled for Android (aarch64-linux-android).
I however don't see any reason why this wouldn't work. `target_os` is "android" on Android and not "linux".
bors [Thu, 11 Aug 2022 22:30:26 +0000 (22:30 +0000)]
Auto merge of #10930 - ehuss:enable-windows-tests, r=weihanglo
Enable two windows tests
These two tests were disabled on Windows a long time ago. AFAICT, the reasons are no longer relevant, and it should be safe to enable these tests. See each commit for a more detailed exposition.
bors [Thu, 11 Aug 2022 03:23:09 +0000 (03:23 +0000)]
Auto merge of #10968 - hi-rustin:rustin-patch-msg, r=ehuss
Improve error msg for get target runner
Actually, we'll get this config from three places. So this msg may be confusing when you set it up in `.cargo/config.toml` or pass it by `--config`.
We already printed the location of the config, so I think it's OK to change it to `configurations`.
bors [Wed, 10 Aug 2022 21:55:46 +0000 (21:55 +0000)]
Auto merge of #10962 - Nemo157:override-target-dir, r=ehuss
Ensure rustc-echo-wrapper works with an overridden build.target-dir
Without this when running with an overridden target-dir there are about a dozen test failures like
```console
> mkdir .cargo
> echo '[build]\ntarget-dir = "not-target"' > .cargo/config
> cargo test -- fix::does_not_crash
---- fix::does_not_crash_with_rustc_wrapper stdout ----
running `/home/nemo157/sources/cargo/not-target/debug/cargo build`
running `/home/nemo157/sources/cargo/not-target/debug/cargo fix --allow-no-vcs`
thread 'fix::does_not_crash_with_rustc_wrapper' panicked at '
test failed running `/home/nemo157/sources/cargo/not-target/debug/cargo fix --allow-no-vcs`
error: process exited with code 101 (expected 0)
--- stdout
--- stderr
error: failed to run `rustc` to learn about target-specific information
Caused by:
could not execute process `/home/nemo157/sources/cargo/not-target/tmp/cit/rustc-echo-wrapper/target/debug/rustc-echo-wrapper rustc - --crate-name ___ --print=file-names --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro --print=sysroot --print=cfg` (never executed)
Caused by:
No such file or directory (os error 2)
', tests/testsuite/fix.rs:1228:10
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Because the `rustc-echo-wrapper` is compiled to `not-target/debug/rustc-echo-wrapper`.
This is resolved by forcing the target-dir to be a manifest-relative one for this specific build.
Josh Triplett [Wed, 10 Aug 2022 15:49:24 +0000 (17:49 +0200)]
Switch back to `available_parallelism`
This reverts commit 8345cf5037506b38457483429fb113322c58f668. Since that
time, there are now multiple calls to get the number of CPUs, to handle
the `-j -NUM` case, so factor out a helper function.
bors [Wed, 10 Aug 2022 14:30:11 +0000 (14:30 +0000)]
Auto merge of #10961 - Nemo157:skip-implicit-override, r=epage
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)
bors [Tue, 9 Aug 2022 22:32:17 +0000 (22:32 +0000)]
Auto merge of #10891 - joshtriplett:rust-version-recommend-precise, r=ehuss
Make the `rust-version` error recommend `cargo update --precise -p crate@ver`
People encountering a dependency with a newer `rust-version` requirement
may not know about `cargo update --precise`, or may consider alternate
approaches that may be harmful (such as pinning with a `=` dependency).
Josh Triplett [Tue, 2 Aug 2022 17:50:46 +0000 (10:50 -0700)]
Only show advice to use `cargo update --precise` for non-local packages
Packages in the local workspace can't get updated this way; the user
just needs to point to a different source, or otherwise update the
package themselves.
Make the `rust-version` error recommend `cargo update -p crate@ver --precise ...`
People encountering a dependency with a newer `rust-version` requirement
may not know about `cargo update --precise`, or may consider alternate
approaches that may be harmful (such as pinning with a `=` dependency).
Provide specific guidance in the error message.
If the user is using `cargo install`, suggest `cargo install --locked` instead.
bors [Sat, 6 Aug 2022 22:45:31 +0000 (22:45 +0000)]
Auto merge of #10946 - RalfJung:docs, r=epage
resolver docs: link to version requirements syntax full explanation
Staring at https://doc.rust-lang.org/cargo/reference/resolver.html#semver-compatibility, I was confused was this is a "refresher" for. Let's add a link to the main documentation this summarizes.
Since the word "xtask" is rather difficult to type in my opinion (at least my left hand struggles quite a bit) I wanted to add another alias, `x` as a shorthand (similar to what `build`, `run`, etc. have by default). Thereby I discovered that I needn't replicate the whole alias, because aliases are recursive. I consulted the docs and couldn't find a mention of this, hence I'm adding it as part of this PR so other users can discover it.
### How should we test and review this PR?
I don't think this requires a separate test, it's a minor change to the documentation only.
bors [Thu, 4 Aug 2022 00:32:49 +0000 (00:32 +0000)]
Auto merge of #10322 - eholk:reserved-windows-name, r=ehuss
Test if reserved filenames are allowed in Windows
Recent versions of Windows have removed the limitation on filenames like `aux` or `con`. This change allows the `package::reserved_windows_name` to still pass by first trying to create a file with a reserved name to see if Windows supports it. If so, it skips the rest of the test. Otherwise, we keep the same behavior as before.
Eric Holk [Mon, 24 Jan 2022 19:09:07 +0000 (11:09 -0800)]
Use GetFullPathNameW to test restricted names
The previous commit tests whether the current machine supports Windows
restricted names by creating a file and checking whether that succeeds.
This commit reworks this testto use GetFullPathNameW, which can be done
without having to create and remove new files.
Eric Holk [Wed, 19 Jan 2022 19:53:06 +0000 (11:53 -0800)]
Test if reserved filenames are allowed in Windows
Recent versions of Windows have removed the limitation on filenames like
`aux` or `con`. This change allows the `package::reserved_windows_name`
to still pass by first trying to create a file with a reserved name to
see if Windows supports it. If so, it skips the rest of the test.
Otherwise, we keep the same behavior as before.
bors [Wed, 3 Aug 2022 15:03:52 +0000 (15:03 +0000)]
Auto merge of #10934 - ehuss:revert-jobserver, r=epage
Revert "Drop check for mingw32-make."
This reverts 8e35e2f044a8a042f9f2eedc35cb6db4649533c9 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.
bors [Wed, 3 Aug 2022 03:54:05 +0000 (03:54 +0000)]
Auto merge of #10929 - ehuss:ignore-reason, r=weihanglo
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
```
bors [Tue, 2 Aug 2022 22:51:23 +0000 (22:51 +0000)]
Auto merge of #10931 - ehuss:ignore-hg, r=weihanglo
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.
Eric Huss [Tue, 2 Aug 2022 19:54:16 +0000 (12:54 -0700)]
Re-enable version_works_without_rustc on windows.
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`.
bors [Tue, 2 Aug 2022 14:41:51 +0000 (14:41 +0000)]
Auto merge of #10918 - ehuss:fix-formats_source, r=Eh2406
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.
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.
bors [Mon, 1 Aug 2022 00:51:01 +0000 (00:51 +0000)]
Auto merge of #9892 - ehuss:cargo_test-ignore-reason, r=weihanglo
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.