### What does this PR try to resolve?
Likely won't make an impact to build times since these dependencies are
still used somewhere but they at least make things clearer. Maybe people
using these crates as libraries can benefit.
### How to test and review this PR?
As found by
```
CARGO_LOG=cargo::core::compiler::unused_deps=debug nargo check --workspace
```
*[View all
comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/cargo/pull/16796)*
### What does this PR try to resolve?
This allows users to either
- hide warnings (#14258)
- error on warnings (#8424)
`build.warnings` serves a similar purpose as `RUSTFLAGS=-Dwarnings` /
`RUSTFLAGS=-Awarnings` but without invalidation caches.
`build.warnings = "deny"` will
- only errors for lint warnings and not hard warnings
- only errors for local warnings and not non-local warnings visible with
`--verbose --verbose`
- stop the build without `--keep-going`
(this matches `RUSTFLAGS=-Dwarnings`)
These conditions were not originally met and also came as feedback from
rust-lang/rust which has been dogfooding this since the merge of
rust-lang/rust#148332.
`build.warnings = "allow"` will
- only hide lint warnings and not hard warnings
- Note: `RUSTFLAGS=-Awarnings` will suppress rustc hard warnings
- hide non-local warnings for `--verbose --verbose`
- hide the warning summary line (number of warnings per crate)
Closes#14802
### How to test and review this PR?
My main concern over this was how the naming scheme would extend to
https://github.com/rust-lang/rfcs/pull/3730 but that RFC has not gained
much interest
`build` seems as good of a home as any.
Fixes#16925
Regressed in #16712 which added validation for explicitly specified
target directories by checking if they contain a valid `CACHEDIR.TAG`.
This PR makes it so that cargo skips this validation if the target-dir
doesn't exist.
### What does this PR try to resolve?
This is a follow up to #16935 where we take a different direction for
false positives.
We are now ignoring unused direct deps that are also transitive deps
(technically still used somewhere). This leaves workflows like `curl`
where the `build.rs` dynamically decides what deps to use but that seems
like enough of an exception case to not worry about direct integration
for.
This means we can punt on having an allowlist to decide what approach we
want take from among rust-lang/rfcs#3920
### How to test and review this PR?
This reverts commit b276acc529.
This reverts commit b276acc529.
This is a follow up to #16935 where we take a different direction for
false positives.
Instead of an allowlist, we will ignore unused direct deps that are also
transitive deps (technically still used somewhere).
This leaves workflows like `curl` where the `build.rs` dynamically
decides what deps to use but that seems like enough of an exception case
to not worry about direct integration for.
### What does this PR try to resolve?
This changes `unused_dependencies` lint to reduce the chance of false
positives while we work out the story of how we want people to response
to false positives (rust-lang/rfcs#3920).
### How to test and review this PR?
My assumption is that I will revert the `ignore` lint control added in
#16600 after this.
Looking at the known cases of false positives, my short term plan is:
- transitive version constraint: don't lint
- transitive feature activation: don't lint
- dynamically used dep (e.g. `build.rs` in `curl`): users must `allow`
Longer term, I'd like to replace this change with either
- `lib = false` from artifact deps
- `cfg(resolver = "versions")`, [#t-cargo > Additional dependency tables
@
💬](https://rust-lang.zulipchat.com/#narrow/channel/246057-t-cargo/topic/Additional.20dependency.20tables/near/590208010)
We can evolve this because the exact nature of warning-by-default lints
is not stable.
This is to ensure these tests still have the intended coverage
regardless of how we work around unused direct deps that are present to
control their transitive presence.
Sometimes cargo will attempt to download `pm` before `bin-uses-pm`,
which causes the expected error to occur before the `[DOWNLOADED]`
message is printed.
Since the test doesn't care about downloading `pm`, we can exclude this
case by matching `...`.
### What does this PR try to resolve?
Follow-up coverage for #13946, which fixed#13555
That fix restored the early return in `github_fast_path` for full commit
hashes, but it did not add a direct test for this path. If this guard
gets removed in a later refactor, CI would not catch it very directly.
I first looked at adding this in the testsuite, but the existing GitHub
fast-path coverage uses the public network, and the GitHub API URL is
built directly in the code. So i went with a small unit test for the
early-return path instead.
### How to test and review this PR?
```bash
cargo +1.95 test --lib github_fast_path_full_hash_returns_needs_fetch
cargo +1.95 fmt --check --all
```
The two dependencies `dep1` and `dep2` are fetched and downloaded at the
same time, leading to nondeterministic output in the test.
Fix this issue by replacing dep1 and dep2 with [..]
Additionally, sometimes the pending request count can be less than the
number of queued requests if the requests finish before the resolver
restarts.
Fix this issue by replacing the pending request count with [..] unless
it's zero, which is stable.
The two dependencies `dep1` and `dep2` are fetched and downloaded at the
same time, leading to nondeterministc output in the test.
Fix this issue by using `unordered()`.
Additionally, sometimes the pending request count can be less than the
number of queued requests if the requests finish before the resolver
restarts.
Fix this issue by replacing the pending request count with [..] unless
it's zero, which is stable.
The new async crate downloader is less deterministic in the order of
downloaded crates. In this test, the setup is to have bar download
successfully, but baz not be available. Then attempt to do a check with
--offline. In the flaky failure case, the setup would be wrong, and
neither bar nor baz would be available because it attempted to download
baz first and failed.
This changes the setup for the test to download both crates, then remove
baz from the cache before testing with --offline
This test was randomly failing because the order that cargo prints the
completion of `d1` and `d2` is not deterministic.
I suspect this is a result of
https://github.com/rust-lang/cargo/pull/16898 which can cause the
parallel fetches to finish in different orders.
This is fixed with `.unordered()` because the order these are printed
isn't important.
The new async crate downloader is less deterministic in the order of
downloaded crates. In this test, the setup is to have bar download
successfully, but baz not be available. Then attempt to do a check with
--offline. In the flaky failure case, the setup would be wrong, and
neither bar nor baz would be available.
This changes the setup for the test to download both crates, then
remove baz from the cache before testing with --offline
This test was randomly failing because the order that cargo prints the
completion of `d1` and `d2` is not deterministic.
I suspect this is a result of
https://github.com/rust-lang/cargo/pull/16898 which can cause the
parallel fetches to finish in different orders.
This is fixed with `.unordered()` because the order these are printed
isn't important.
This replaces the `gh-pages` git branch deployment with the official
`actions/upload-pages-artifact` and `actions/deploy-pages` actions.
It requires changing the repository's Pages settings from "Deploy from a
branch" to "GitHub Actions" as described also in
https://github.com/rust-lang/rfcs/pull/3419, which has used a similar
setup for a while now.
I've tested the `build` job in my forked repo and verified that the
artifact contents match the current content of the `gh-pages` branch. I
did not test the `deploy` job with my fork repo, but since it is the
same as in e.g. the `rfcs` repo I don't expect any issues from that.
This allows users to either
- hide warnings (#14258)
- error on warnings (#8424)
`build.warnings` is setup to mirror the behavior of `RUSTFLAGS=-Dwarnings`,
including
- only errors for lint warnings and not hard warnings
- only errors for local warnings and not non-local warnings visible with
`--verbose --verbose`
- stop the build without `--keep-going`
These conditions were not originally met and also came as feedback from
rust-lang/rust which has been dogfooding this since the merge of rust-lang/rust#148332.
Things are a bit different with `RUSTFLAGS=-Awarnings`:
- Hard warnings are hidden for rustc but not cargo (rustc seems in the
wrong imo)
- In particular, we shouldn't mask the edition warning for Cargo
Script
- both hide the warning summary line (number of warnings per crate)
- both hide non-local warnings for `--verbose --verbose`
One design constraint we are operating on with this is that changing
`build.warnings` should not cause a rebuild, unlike a `RUSTFLAGS`
solution.
Closes#14802
### What does this PR try to resolve?
- Add a new `request_blocking` function to the `http_async` module. This
function does not start an executor and runs the request on the current
thread, preventing #16860
- Migrates the GitHub fastpath to use the blocking http_async client.
cc #16845
### How to test and review this PR?
Commit by commit. All commits pass tests.
`CNAME` files are apparently ignored if GitHub Pages are deployed via GitHub Actions and instead the custom domain needs to be set in the repository settings.
