Warning when precise or aggressive without -p flag
### What does this PR try to resolve?
ref https://github.com/rust-lang/cargo/issues/10919.
Warning when precise or aggressive without -p flag. It will be a hard error in future.
### How should we test and review this PR?
- Unit test.
Improve error message for an array value in the manifest
Fixes https://github.com/rust-lang/cargo/issues/10942
The error message will be:
```
error: failed to parse manifest at `/Users/..`
Caused by:
invalid type: string "Ky", expected an array for key `package.authors`
```
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".
[docs] Remove extra "in" from `cargo-test.md`
Removes an extra "in" from doc src/doc/src/commands/cargo-test.md
Successor to #10971 without bungled merge
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.
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`.
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.
Switch back to `available_parallelism`
This reverts commit 8345cf5037 now that https://github.com/rust-lang/rust/pull/97925 is merged.
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.
This reverts commit 8345cf5037. 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.
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)
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).
Provide specific guidance in the error message.
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.
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.
Mark --timings=html unstable in the document
### What does this PR try to resolve?
Mark -timings=html unstable in the document. The document was confusing because if you try `--timings=html` it still requires the unstable flag.
### How should we test and review this PR?
Check out the document.
### Additional information
Other information you want to mention in this PR, such as prior arts,
future extensions, an unresolved problem, or a TODO list.
Mention that aliases are recursive
Instead of duplicating portions of commands that are used identically across many aliases, the user can instead reuse any previously defined aliases.
### What does this PR try to resolve?
Today I started working with [`xtask`](https://github.com/matklad/cargo-xtask/), which is a build system based on a simple cargo alias:
```toml
[alias]
xtask = "run --package xtask --"
```
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.
### Additional information
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.
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.
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.
