This fixes the `standard_lib::shared_std_dependency_rebuild` test while
running on Windows. On my system, `CARGO_MANIFEST_DIR` is a normal
windows-style path (`D:\rust\cargo`) with backslashes. That is not valid
TOML syntax. I don't know why this doesn't fail on CI (maybe CI sets a
unix-style current dir?).
This fixes some warnings that show up on Windows:
```
warning: unused variable: `path`
--> tests\testsuite\registry.rs:3146:24
|
3146 | fn set_permissions(path: &Path, permissions: u32) {
| ^^^^ help: if this is intentional, prefix it with an underscore: `_path`
|
= note: `#[warn(unused_variables)]` on by default
warning: unused variable: `permissions`
--> tests\testsuite\registry.rs:3146:37
|
3146 | fn set_permissions(path: &Path, permissions: u32) {
| ^^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_permissions`
```
### What does this PR try to resolve?
This came up in #13623 to avoid putting tokens into shell history.
### How should we test and review this PR?
The exact approach to deprecation can vary
- Include `<token>` in at least some docs for discovery (most likely the
man page)
- Don't warn yet
etc
I also suspect we could reorganize `cargo help login` but wanted to
decouple that from this change.
### Additional information
Nightly recently introduced the `linker-messages` lint which prints any
messages from linkers. These tests were triggering that lint because
they were passing missing directories to the linker. This fixes it by
creating empty directories to pass to the linker.
Note that this lint will be downgraded soon via
https://github.com/rust-lang/rust/pull/136098, but it seemed worthwhile
to fix the underlying problem.
This also fixes a problem where build_script_needed_for_host_and_target
was not testing for the correct command-line flags. These got lost
in https://github.com/rust-lang/cargo/pull/14132.
That's a gcc flag. lld is a linker, not a C compiler, and doesn't accept
a `use-ld` flag. `-C linker=rust-lld` (which is already present in the
test) is enough.
This fixes the following warning found in rust-lang/rust#119286:
```
---- expected: tests\testsuite\freshness.rs:2822:27
++++ actual: stderr
1 1 | [FRESH] foo v0.1.0 ([ROOT]/foo)
2 + [WARNING] linker stderr: rust-lld: ignoring unknown argument '-fuse-ld=lld'␍
3 + |
4 + = [NOTE] `#[warn(linker_messages)]` on by default
5 +
6 + [WARNING] `foo` (lib) generated 1 warning
2 7 | [FINISHED] `dev` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s
```
<!--
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.
-->
That's a gcc flag. lld is a linker, not a C compiler, and doesn't accept
a `use-ld` flag. `-C linker` (which is already present in the test) is
enough.
This fixes the following warning found in rust-lang/rust#119286:
```
---- expected: tests\testsuite\freshness.rs:2822:27
++++ actual: stderr
1 1 | [FRESH] foo v0.1.0 ([ROOT]/foo)
2 + [WARNING] linker stderr: rust-lld: ignoring unknown argument '-fuse-ld=lld'␍
3 + |
4 + = [NOTE] `#[warn(linker_messages)]` on by default
5 +
6 + [WARNING] `foo` (lib) generated 1 warning
2 7 | [FINISHED] `dev` profile [unoptimized + debuginfo] target(s) in [ELAPSED]s
```
Staged changes don't really need protecting, and `--allow-dirty` is
stronger than `--allow-staged`, so it can imply `--allow-staged` to make
usage of `cargo fix` less verbose.
Closes#14176
### What does this PR try to resolve?
I didn't extend this to multiple packages restricted to specific
registries.
It seems less likely to be a problem and more complex to gather and
report.
This was inspired by feedback left at #10948
### How should we test and review this PR?
### Additional information
I didn't extend this to multiple packages restricted to specific
registries.
It seems less likely to be a problem and more complex to gather and
report.
This was inspired by feedback left at #10948
<!--
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?
Fixes#13712
Adds a warning if there is an error updating the index cache.
It also attempts to avoid warning spam as requested in [this
comment](https://github.com/rust-lang/cargo/issues/13712#issuecomment-2514991597)
Below is an example output
```
Updating crates.io index
warning: failed to write cache, path: /home/ross/.cargo/registry/index/index.crates.io-1949cf8c6b5b557f/.cache/ba/se/base64, error: Permission denied (os error 13)
Compiling serde v1.0.217
Compiling r-efi v5.2.0
Compiling base64 v0.22.1
Compiling cargo-13712 v0.1.0 (/home/ross/projects/cargo-13712)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.20s
```
### How should we test and review this PR?
I tested this on my machine by manually changing the owner/permission of
the index files
```sh
sudo chown root ~/.cargo/registry/index/.../.cache/r-
sudo chmod 700 ~/.cargo/registry/index/.../.cache/r-
# in a project that uses the `r-efi` crate
cargo build
```
I wasn't quiet sure about the best way to add a test to the testsuite
for this. 😅
If there is good way to create a test for this lmk
### What does this PR try to resolve?
This is a horrible hack,
which lets the rustc invocation for learning target info always emit
warnings as warnings.
But at least it unblocks people who pass `-Awarnings` via RUSTFLAGS.
A long-term solution is a better interface
between build systems and the compiler.
See the discussion on Zulip:
https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Improving.20communication.20interface.20between.20cargo.2FrustcFixesrust-lang/cargo#8010
### How should we test and review this PR?
Ensure `CFG_DISABLE_CROSS_TESTS` is not set,
and run `cargo t --test testsuite
always_emit_warnings_as_warnings_when_learning_target_info`
This also additionally adds `wasm32-unknown-unknown` target to Cargo's
CI.
### Additional information
It turns out, running `cargo rustc --print cfg -Zunstable-options` (and
the like, https://github.com/rust-lang/cargo/issues/9357) fail with
`.cargo/config.toml` setups like
```toml
[build]
# custom target json that lives in `./targets/my-super-cool-target.json`
target = "my-super-cool-target"
[env]
RUST_TARGET_PATH = { value = "./targets", relative = true }
```
resulting in
```
❯ cargo rustc --print cfg -Zunstable-options
error: Error loading target specification: Could not find specification for target "my-super-cool-target". Run `rustc --print target-list` for a list of built-in targets
error: process didn't exit successfully: `C:\Users\lukas\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\bin\rustc.exe --target my-super-cool-target --print cfg` (exit code: 1)
```
The reason for that is that cargo recognizes the target from the
`.cargo/config` and then implicitly passes that along to the spawned
rustc process, but it does so without passing along the important
environment that is required for the target tuple to make sense.
(can add a test if desired, just tell me where)
This no longer generates the same error message for the same reason that
it changed for linux in https://github.com/rust-lang/cargo/pull/13970.
Note that Windows does things slightly differently, and doesn't need
adjustment.
