chore: Mark unpublished crates as such
This is a follow up to #12039.
This makes it easier for tools to report less irrelevant information.
I did both `publish = false` and `version = "0.0.0"` to help draw attention to the fact that these crates are internal (inspired by a matklad post).
I left `cargo-test-macro` and `cargo-test-support` in for my own personal bias of one day wanting to see those crates published...
The only one removed that had previously been published was `mdman` but seeing as that was a `0.0.0`, I'm assuming that was a mistake or just reserving the name.
Before:
```console
$ cargo unpublished
name published current
==== ========= =======
cargo-platform 0.1.2 0.1.3
cargo-test-macro - 0.1.0
cargo-test-support - 0.1.0
cargo-util 0.2.3 0.2.4
crates-io 0.36.0 0.36.1
mdman 0.0.0 0.1.0
resolver-tests - 0.1.0
cargo 0.70.1 0.72.0
semver-check - 0.1.0
cargo-credential 0.1.0 0.2.0
cargo-credential-1password 0.1.0 0.2.0
cargo-credential-gnome-secret 0.1.0 0.2.0
cargo-credential-macos-keychain 0.1.0 0.2.0
cargo-credential-wincred 0.1.0 0.2.0
benchsuite - 0.1.0
```
After:
```console
name published current
==== ========= =======
cargo-platform 0.1.2 0.1.3
cargo-test-macro - 0.1.0
cargo-test-support - 0.1.0
cargo-util 0.2.3 0.2.4
crates-io 0.36.0 0.36.1
cargo 0.70.1 0.72.0
cargo-credential 0.1.0 0.2.0
cargo-credential-1password 0.1.0 0.2.0
cargo-credential-gnome-secret 0.1.0 0.2.0
cargo-credential-macos-keychain 0.1.0 0.2.0
cargo-credential-wincred 0.1.0 0.2.0
```
chore(xtask): Add `cargo xtask unpublished`
### What does this PR try to resolve?
This tries to make it easy to see what existing versions have not been published. A future version of this could post to a PR what the current delta in version numbers for touched crates so reviewer have more context when deciding if they should ask for a crate version to be bumped
```console
$ cargo unpublished
Finished dev [unoptimized + debuginfo] target(s) in 0.12s
Running `/home/epage/src/personal/cargo/target/debug/xtask unpublished`
Updating crates.io index
name published current
==== ========= =======
cargo-test-macro - 0.1.0
cargo-test-support - 0.1.0
cargo-util 0.2.3 0.2.4
mdman 0.0.0 0.1.0
resolver-tests - 0.1.0
cargo 0.70.0 0.71.0
cargo-credential 0.1.0 0.2.0
cargo-credential-1password 0.1.0 0.2.0
cargo-credential-gnome-secret 0.1.0 0.2.0
cargo-credential-macos-keychain 0.1.0 0.2.0
cargo-credential-wincred 0.1.0 0.2.0
benchsuite - 0.1.0
```
Room for improvement
- Aligning the start of each column
- Filtering the list by a commit range
- Adding this to an action to post to a review
- Maybe sorting the output
- Marking some our crates as `package.publish = false`, like benchsuite and resolver-tests
### How should we test and review this PR?
This is broken down commit by commit for easier seeing of the building blocks for our first xtask
This is a follow up to #12039.
This makes it easier for tools to report less irrelevant information.
I did both `publish = false` and `version = "0.0.0"` to help draw
attention to the fact that these crates are internal (inspired by a
matklad post).
I left `cargo-test-macro` and `cargo-test-support` in for my own
personal bias of one day wanting to see those crates published...
The only one removed that had previously been published was `mdman` but
seeing as that was a `0.0.0`, I'm assuming that was a mistake or just
reserving the name.
Before:
```console
$ cargo unpublished
name published current
==== ========= =======
cargo-platform 0.1.2 0.1.3
cargo-test-macro - 0.1.0
cargo-test-support - 0.1.0
cargo-util 0.2.3 0.2.4
crates-io 0.36.0 0.36.1
mdman 0.0.0 0.1.0
resolver-tests - 0.1.0
cargo 0.70.1 0.72.0
semver-check - 0.1.0
cargo-credential 0.1.0 0.2.0
cargo-credential-1password 0.1.0 0.2.0
cargo-credential-gnome-secret 0.1.0 0.2.0
cargo-credential-macos-keychain 0.1.0 0.2.0
cargo-credential-wincred 0.1.0 0.2.0
benchsuite - 0.1.0
```
After:
```console
name published current
==== ========= =======
cargo-platform 0.1.2 0.1.3
cargo-test-macro - 0.1.0
cargo-test-support - 0.1.0
cargo-util 0.2.3 0.2.4
crates-io 0.36.0 0.36.1
cargo 0.70.1 0.72.0
cargo-credential 0.1.0 0.2.0
cargo-credential-1password 0.1.0 0.2.0
cargo-credential-gnome-secret 0.1.0 0.2.0
cargo-credential-macos-keychain 0.1.0 0.2.0
cargo-credential-wincred 0.1.0 0.2.0
```
crates.io reads rust-version from the tarball directly, but we can include it in
the publish request for the sake of consistency for third-party registries.
This will allow running an xtask without requiring building the world.
In most cases, a user will already have been building cargo but not in
CI.
The packages keep an `xtask-` prefix to help raise awareness of them but
exposed as `cargo <suffix>` to avoid having a direction proxy to wrap
`cargo run -p xtask-<suffix>` as `cargo xtask <suffix>`.
Update windows-sys
This updates the windows-sys dependency from 0.45 to 0.48. This shouldn't add or remove any duplicate dependencies (since there are other dependencies still using 0.45 and 0.42). The intent is to move it along the direction towards unifying in the future (though it seems like a moving target that will be difficult to ever hit).
This also bumps the home crate version. I think it should be OK to make the migration from winapi to windows-sys a patch version, though there seems to be some issues with the way windows-sys works that could introduce some build-time problems in some situations (such as those encountered in https://github.com/rust-lang/rust/pull/108665 and https://github.com/rust-lang/rust/pull/106610). However, I don't expect too much of an issue.
This is a short-term option until we can have a better solution for
globbing. This does not update `benches/` to support which has a README
in there preventing globbing; this seems low-churn enough not to find a
solution for it.
On the next sync-up with rust-lang/rust, we'll need to update 4e46301258/src/bootstrap/tool.rs (L588-L603)Fixes#11988
Fix credential token format validation.
The existing validation incorrectly excluded tab because of a missing backslash. This updates to add the backslash.
This also rewords the comments. I found the current comments to be a little confusing.
This also extends the test to verify more valid inputs.
cc #11600
Poll loop fixes
### What does this PR try to resolve?
A couple of minor issues. See individual commits.
### How should we test and review this PR?
The existing test suite should have sufficient coverage.
### Additional information
(I have 5 apparently unrelated failures locally when running `cargo test`)
Add more information to wait-for-publish
This reworks the console output when waiting for a publish to be available:
* Shows a "Published" status to try to make it clear that the publish is complete, and that Cargo is moving to a separate phase.
* Removes the repeated status bars and updating messages, and uses a single progress bar to track the publish.
* Provides more of a description of why Cargo is waiting to try to make it clearer what is happening.
* Provides more information when a timeout happens to try to explain what might be happening.
* Shows a "Completed" message at the end to let the user know that everything is complete.
Comparing the output:
Before (with git):
```
Updating crates.io index
Packaging delay v0.0.2 (/Users/eric/Proj/rust/cargo/target/tmp/cit/t0/foo)
Packaged 3 files, 761.0B (569.0B compressed)
Uploading delay v0.4.27 (/Users/eric/Proj/rust/cargo/target/tmp/cit/t0/foo)
Updating crates.io index
Waiting on `delay` to propagate to crates.io index (ctrl-c to wait asynchronously)
Updating crates.io index
Updating crates.io index
Updating crates.io index
Updating crates.io index
Updating crates.io index
Updating crates.io index
Updating crates.io index
Updating crates.io index
Updating crates.io index
Updating crates.io index
```
Before (with sparse):
```
Updating crates.io index
Packaging delay v0.0.2 (/Users/eric/Proj/rust/cargo/target/tmp/cit/t0/foo)
Packaged 3 files, 761.0B (569.0B compressed)
Uploading delay v0.0.2 (/Users/eric/Proj/rust/cargo/target/tmp/cit/t0/foo)
Updating crates.io index
Waiting on `delay` to propagate to crates.io index (ctrl-c to wait asynchronously)
Fetch [=============================> ] 36 complete; 1 pending
```
New (git or sparse):
```
Updating crates.io index
Packaging delay v0.0.2 (/Users/eric/Proj/rust/cargo/target/tmp/cit/t0/foo)
Packaged 3 files, 761.0B (569.0B compressed)
Uploading delay v0.0.2 (/Users/eric/Proj/rust/cargo/target/tmp/cit/t0/foo)
Uploaded delay v0.0.2 (/Users/eric/Proj/rust/cargo/target/tmp/cit/t0/foo)
note: Waiting for `delay@0.0.2` to be available at registry `crates-io`.
You may press ctrl-c to skip waiting; the crate should be available shortly.
Waiting [===> ] 11/60
Published delay v0.0.2 (/Users/eric/Proj/rust/cargo/target/tmp/cit/t0/foo) has been successfully published to registry `crates-io`
```
(Note: In the last two cases the progress bar disappears when it is done, I have just included it here to illustrate.)
Fixes#11304
This is to help prepare for checking for doc warnings across the entire
workspace being created in rust-lang/cargo#11851
`Mutation` was made `pub`, along with its fields, but they aren't
actually usable with anything, so I went and made it private to match
what its documentation references
This allows to use `gitoxide` for all fetch operations, boosting performance
for fetching the `crates.io` index by a factor of 2.2x, while being consistent
on all platforms.
For trying it, nightly builds of `cargo` can specify `-Zgitoxide=fetch`.
It's also possible to set the `__CARGO_USE_GITOXIDE_INSTEAD_OF_GIT2=1` environment
variable (value matters), which is when `-Zgitoxide=none` can be used
to use `git2` instead.
Limitations
-----------
Note that what follows are current shortcomings that will be addressed in future PRs.
- it's likely that authentication around the `ssh` protocol will work differently in practice
as it uses the `ssh` program.
- clones from `file://` based crates indices will need the `git` binary to serve the locatl repository.
- the progress bar shown when fetching doesn't work like the orgiinal, but should already feel 'faster'.
feat(resolver): `-Zdirect-minimal-versions`
This is an alternative to `-Zminimal-versions` as discussed in #5657.
Problems with `-Zminimal-versions` includes
- Requires the root most dependencies to verify it and we then percolate that up the stack. This requires a massive level of cooperation to accomplish and so far there have been mixed results with it to the point that cargo's unstable
documentation discourages its use.
- Users expect `cargo check -Zminimal-versions` to force resolving to minimal but it doesn't as the default maximal resolve is compatible and requires `cargo update -Zminimal-versions`
- Different compatible versions might be selected, breaking interop between crates, changing feature unification, and breaking `-sys` crates without bad `links`
`-Zdirect-minimal-versions` instead only applies this rule to your
direct dependencies, allowing anyone in the stack to immediately adopt
it, independent of everyone else.
Special notes
- Living up to the name and the existing design, this ignores yanked
crates. This makes sense for `^1.1` version requirements but might
look weird for `^1.1.1` version requirements as it could select
`1.1.2`.
- This will error if an indirect dependency requires a newer version.
Your version requirement will need to capture what you use **and** all
of you dependencies. An alternative design would have tried to merge
the result of minimum versions for direct dependencies and maximum
versions for indirect dependencies. This would have been complex and
led to weird corner cases, making it harder to predict. I also suspect
the value gained would be relatively low as you can't verify that
version requirement in any other way.
- This also means discrepancies between `dependencies` and `dev-dependencies` are errors
- The error could be improved to call out that this was from minimal
versions but I felt getting this out now and starting to collect
feedback was more important.
One advantage of this approach over `-Zminimal-versions` is that it removes most of the problems that [cargo-minimal-versions](https://github.com/taiki-e/cargo-minimal-versions) tried to workaround.
As for the implementation, this might not be the most elegant solution but it works and we can always iterate and improve on it in the future.
- We keep the state as a `bool` throughout but compensate for that by explicitly creating a variable to abstract away constants
- The name changes depending on the context, from `direct_minimal_version` when dealing with the unstable flag to `first_minimal_version` when the concept of "direct" is lost to `first_version` when we split off the ordering concept into a separate variable
- Packages that respect `direct_minimal_versions` are determined by whether they are the top-level `summaries` that get past into `resolve`
### What does this PR try to resolve?
The primary use case is verifying version requirements to avoid depending on something newer than might be available in a dependent
For this to help the MSRV use case, the crate author must directly depend on all indirect dependencies where their latest release has too new of an MSRV but at least they can do so with the `^` operator, rather than `<` and breaking the ecosystem.
### How should we test and review this PR?
The first two commits add tests using `-Zminimal-versions`. The commit that adds `-Zdirect-minimal-versions` updates the tests, highlighting the differences in behavior.
### Additional information
Potential areas of conversation for stablization
- Flag name
- Handling of yanked (pick first non-yanked, pick yanked, error)
- Quality of error message
- Should the package have a "memory" of this flag being set by writing it to the lockfile?
Potential future work
- Stablize this
- Remove `-Zminimal-versions`
- Update `cargo publish`s `--verify` step to use this.
- The challenge is this won't be using the packaged `Cargo.lock` which probably should also be verified.
* moved `is_empty` check into `check_token`
* improved error message (is quite long now but should explain the error
well)
* removed one helper function from new test
When using registry operations with authentication there will be now an
error if the given token is not valid.
This is a technically a breaking change because a registry might give
some tokens which will be denied by these new checks.
In practice these tokens cause issues with HTTP so no registry should
generate them.
- Revert most of changes to expected test output from commit 2a4ec9f2.
- Keep later changes to expected test output from commit 0263ef43.
- Change test input that's converted to trigger similar output as previously.
This is an alternative to `-Zminimal-versions` as discussed in #5657.
The problem with `-Zminimal-versions` is it requires the root most
dependencies to verify it and we then percolate that up the stack. This
requires a massive level of cooperation to accomplish and so far there
have been mixed results with it to the point that cargo's unstable
documentation discourages its use.
`-Zdirect-minimal-versions` instead only applies this rule to your
direct dependencies, allowing anyone in the stack to immediately adopt
it, independent of everyone else.
Special notes
- Living up to the name and the existing design, this ignores yanked
crates. This makes sense for `^1.1` version requirements but might
look weird for `^1.1.1` version requirements as it could select
`1.1.2`.
- This will error if an indirect dependency requires a newer version.
Your version requirement will need to capture what you use **and** all
of you dependencies. An alternative design would have tried to merge
the result of minimum versions for direct dependencies and maximum
versions for indirect dependencies. This would have been complex and
led to weird corner cases, making it harder to predict. I also suspect
the value gained would be relatively low as you can't verify that
version requirement in any other way.
- The error could be improved to call out that this was from minimal
versions but I felt getting this out now and starting to collect
feedback was more important.
Deny warnings in CI, not locally
### What does this PR try to resolve?
The problem with #![deny(warnings)] is it makes iteration more difficult as you might have intermediate states with warnings. Its slightly better that we defer this to cargo test --lib but that still means you can't run a subset of tests against your experiment until you've cleaned up all of your warnings. This can lead to users [working around the problem which could accidentally slip in](d92d04840c).
### How should we test and review this PR?
The first round for this PR includes a warning in the `cargo` crate to ensure it breaks CI. It will then be reverted.
### Additional information
See also https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/.60.23!.5Bcfg_attr.28test.2C.20deny.28warnings.29.29.5D.60
Replace `winapi` with `windows-sys` crate.
### What does this PR try to resolve?
replace `winapi` with `windows-sys` crate.
It's officially maintained.
### How should we test and review this PR?
I just do the replacement of API. I think it is quite clear.
And I found a `cfg` for `windows` may miss checked error.
### Additional information
No one.
Make cargo aware of dwp files.
When using -Csplit-debuginfo=packed on Linux, rustc will produce a dwp file. Unlike the dwo files, whose paths are embedded into the binary, there's no information in the binary to help a debugger locate a dwp file. By convention, the dwp file for `<EXE>` is given the name `<EXE>.dwp` and placed next to `<EXE>`.
When cargo hardlinks the executable file rustc put in target/debug/deps into target/debug, it also needs to hardlink the dwp file along with it. Failing to do this prevents the debugger from finding the dwp file when the binary is executed from target/debug, as there's no way for the debugger to know to look in the deps subdirectory.
The split_debuginfo option is passed down into file_types to make this possible. For cargo clean manual handling is added to match the other split_debuginfo files. bin_link_for_target also passes in None because it won't care about the dwp file.
When using -Csplit-debuginfo=packed on Linux, rustc will produce a dwp file.
Unlike the dwo files, whose paths are embedded into the binary, there's no
information in the binary to help a debugger locate a dwp file. By convention,
the dwp file for <EXE> is given the name <EXE>.dwp and placed next to <EXE>.
When cargo hardlinks the executable file rustc put in target/debug/deps into
target/debug, it also needs to hardlink the dwp file along with it. Failing to
do this prevents the debugger from finding the dwp file when the binary is
executed from target/debug, as there's no way for the debugger to know to look
in the deps subdirectory.
chore: Fix typos
Seeing several typo PRs, like #11560, I figured I'd run my source code spell checker on cargo to help catch a lot of these earlier, in one big batch.
There is a soundness issue with atty when building on Windows with a
custom allocator.
This PR switches direct dependencies on atty to is-terminal. New semver
compatible versions of clap and snapbox remove atty. #11417 upgrades
env_logger to remove it from there.
Fixes#11415
Change rustdoc-scrape-examples to be a target-level configuration
This PR addresses issues raised in rust-lang/cargo#9525. Specifically:
1. It enables examples to be scraped from `#[test]` functions, by passing additional flags to Rustdoc to ensure that these functions aren't ignored by rustc.
2. It moves the `arg` from `-Z rustdoc-scrape-examples={arg}` into a target-level configuration that can be added to Cargo.toml.
The added test `scrape_examples_configure_target` shows a concrete example. In short, examples will be default scraped from Example and Lib targets. Then the user can enable or disable scraping like so:
```toml
[lib]
doc-scrape-examples = false
[[test]]
name = "my_test"
doc-scrape-examples = true
```
chore: Upgrade dependencies
This upgrades several dependencies to the latest "major" release. The original intent was just to get onto the latest snapbox but I noticed several others that could be updated and thought "why not".
- `snapbox` broke compatibility on less used APIs
- Its unclear from the docs if `miow` or `remove_dir_all` even broke compatibility
I did not touch `mdman` as that has several large, stale deps
Make cargo forward pre-existing CARGO if set
Currently, Cargo will always set `$CARGO` to point to what it detects its own path to be (using `std::env::current_exe`). Unfortunately, this runs into trouble when Cargo is used as a library, or when `current_exe` is not actually the binary itself (e.g., when invoked through Valgrind or `ld.so`), since `$CARGO` will not point at something that can be used as `cargo`. This, in turn, means that users can't currently rely on `$CARGO` to do the right thing, and will sometimes have to invoke `cargo` directly from `$PATH` instead, which may not reflect the `cargo` that's currently in use.
This patch makes Cargo re-use the existing value of `$CARGO` if it's already set in the environment. For Cargo subcommands, this will mean that the initial invocation of `cargo` in `cargo foo` will set `$CARGO`, and then Cargo-as-a-library inside of `cargo-foo` will inherit that (correct) value instead of overwriting it with the incorrect value `cargo-foo`. For other execution environments that do not have `cargo` in their call stack, it gives them the opportunity to set a working value for `$CARGO`.
One note about the implementation of this is that the test suite now needs to override `$CARGO` explicitly so that the _user's_ `$CARGO` does not interfere with the contents of the tests. It _could_ remove `$CARGO` instead, but overriding it seemed less error-prone.
Fixes#10119.
Fixes#10113.
Currently, Cargo will always set `$CARGO` to point to what it detects
its own path to be (using `std::env::current_exe`). Unfortunately, this
runs into trouble when Cargo is used as a library, or when `current_exe`
is not actually the binary itself (e.g., when invoked through Valgrind
or `ld.so`), since `$CARGO` will not point at something that can be used
as `cargo`. This, in turn, means that users can't currently rely on
`$CARGO` to do the right thing, and will sometimes have to invoke
`cargo` directly from `$PATH` instead, which may not reflect the `cargo`
that's currently in use.
This patch makes Cargo re-use the existing value of `$CARGO` if it's
already set in the environment. For Cargo subcommands, this will mean
that the initial invocation of `cargo` in `cargo foo` will set `$CARGO`,
and then Cargo-as-a-library inside of `cargo-foo` will inherit that
(correct) value instead of overwriting it with the incorrect value
`cargo-foo`. For other execution environments that do not have `cargo`
in their call stack, it gives them the opportunity to set a working
value for `$CARGO`.
One note about the implementation of this is that the test suite now
needs to override `$CARGO` explicitly so that the _user's_ `$CARGO` does
not interfere with the contents of the tests. It _could_ remove `$CARGO`
instead, but overriding it seemed less error-prone.
Fixes#10119.
Fixes#10113.
Originally, crates.io would block on publish requests until the publish
was complete, giving `cargo publish` this behavior by extension. When
crates.io switched to asynchronous publishing, this intermittently broke
people's workflows when publishing multiple crates. I say interittent
because it usually works until it doesn't and it is unclear why to the
end user because it will be published by the time they check. In the
end, callers tend to either put in timeouts (and pray), poll the
server's API, or use `crates-index` crate to poll the index.
This isn't sufficient because
- For any new interested party, this is a pit of failure they'll fall
into
- crates-index has re-implemented index support incorrectly in the past,
currently doesn't handle auth, doesn't support `git-cli`, etc.
- None of these previous options work if we were to implement
workspace-publish support (#1169)
- The new sparse registry might increase the publish times, making the
delay easier to hit manually
- The new sparse registry goes through CDNs so checking the server's API
might not be sufficient
- Once the sparse registry is available, crates-index users will find
out when the package is ready in git but it might not be ready through
the sparse registry because of CDNs
This introduces unstable support for blocking by setting
`publish.timeout` to non-zero value.
A step towards #9507
Bump git2 to 0.15 and libgit2-sys to 0.14
This will allow cargo to avoid vendored builds of git2 in up-to-date
environments going forward, and brings in the [libgit2 1.4.4 CVE fix].
[libgit2 1.4.4 CVE fix]: https://github.com/libgit2/libgit2/releases/tag/v1.4.4
This will allow cargo to avoid vendored builds of git2 in up-to-date
environments going forward, and brings in the [libgit2 1.4.4 CVE fix].
[libgit2 1.4.4 CVE fix]: https://github.com/libgit2/libgit2/releases/tag/v1.4.4
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
```
In writing the contrib documentation for functional vs ui tests, I
realized that as we work to make snapbox work for the functional tests,
we'll need distinct `Assert` objects since we'll want to elide a lot
more content in functional tests. I'm making room for this by
qualifying the existing asserts as being for "ui".
