Change verification order during packaging.
Once we support packaging workspaces with dependencies, dependency packages need to be built before anything is verified. In addition to a little refactoring, this commit reorders the console messages so that package metadata (archive size, etc.) is reported before verification results.
As [suggested](ecba15ca99 (r1640182916)) on #13947 this, splits out the first commit (which has a lot of test output churn) as a separate PR.
Once we support packaging workspaces with dependencies, dependency
packages need to be built before anything is verified. In addition to a
little refactoring, this commit reorders the console messages so that
package metadata (archive size, etc.) is reported before verification
results.
Co-Authored-By: Tor Hovland <55164+torhovland@users.noreply.github.com>
I got a CI failure because the following line showed up:
```
[WARNING] build failed, waiting for other jobs to finish...
```
I'm assumin this is a race condition in the test for whether the
successful target completed before the error or not.
Before snapbox, we used a `contains` check which didn't have this
problem. I'm replacing this with a `...` multi-line (0+) glob.
Migrate a few test files to snapbox
This migrates the following files to `snapbox`
- `artifact_dep`
- Has a few `does_not_contain`
- `artifact_dir`
- `bad_config`
- `bad_manifest_path`
- Does not use `str!` for all tests
- `bench`
Note: This also adds auto-redactions for:
- `[HOST_TARGET]`
- `[ALT_TARGET]`
- Only added if cross-compilation is allowed for the target
- `[AVG_ELAPSED]`
- For `bench` output
- `[JITTER]`
- For `bench` output
Part of #14039
This reverts commit fa619a9d16ca0d4dc58431808c08b7c1fee72bfa, reversing
changes made to 1f6857dcfbe84ce3e8edd26f861ee8bae0c5da2b.
See also <https://github.com/rust-lang/rust/pull/115120>
test: migrate features_are_quoted to snapbox
### What does this PR try to resolve?
Part of https://github.com/rust-lang/cargo/issues/14039.
Migrate `tests/testsuite/shell_quoting.rs` to snapbox.
### How should we test and review this PR?
N/A
### Additional information
N/A
Add assert redactions
This was split out from #14048 so that the test changes in that PR do not block the redactions.
This adds auto-redactions for:
- A new `[HASH]` for `/<file>-<16 char hash>`
- `[HOST_TARGET]`
- `[ALT_TARGET]`
- Only added if cross-compilation is allowed for the target
- `[AVG_ELAPSED]`
- For `bench` output
- `[JITTER]`
- For `bench` output
This also moves all common redactions to a function that `assert_e2e` and `assert_ui` call to reduce the amount of duplicate code and makes it so we only compile regex redactions once.
Add local registry overlays
This PR adds (private to cargo internals) support for local registry overlays, in which you can locally pretend to add packages to remote registries; the local packages will have the same source ids as the remote registry that you're overlaying.
There are two ways to set up these overlays: programmatically using `GlobalContext::local_overlays` and through the `__CARGO_TEST_PACKAGE_CONFUSION_VULNERABILITY_DO_NOT_USE_THIS` environment variable. You can't set up these overlays with `.cargo/config`.
The motivation for this is [packaging workspaces](https://github.com/rust-lang/cargo/issues/10948). When we're packing a workspace, we'd like to be able to pretend (for lockfile generation and verification) that some workspace packages are already published even though they aren't.
tests: Migrate alt_registry to snapbox
### What does this PR try to resolve?
The overall goal is to enable the use of snapshot testing on as many cargo tests as possible to reduce the burden when having to touch a lot of tests. Towards that aim, this PR
- Adds snapshot testing to `cargo_test_support::Execs`
- Migrates `alt_registry` tests over as an example (and to vet it)
I've taken the approach of deprecating all other output assertions on `Execs` with `#[allow(deprecated)]` in every test file. This let's us easily identity what files haven't been migrated, what in a file needs migration, and helps prevent a file from regressing. This should make it easier to do a gradual migration that (as many people as they want) can chip in. It comes at the cost of losing visibility into deprecated items we use. Hopefully we won't be in this intermediate state for too long.
To reduce manual touch ups of snapshots, I've added some regex redactions. My main concern with the `FILE_SIZE` redaction was when we test for specific sizes. That shouldn't be a problem because we don't use `Execs::with_stderr` to test those but we capture the output and have a custom asserter for it.
### How should we test and review this PR?
Yes, this puts us in an intermediate state which isn't ideal but much better than one person trying to do all of this in a single branch / PR.
The main risk is that we'll hit a snag with snapbox being able to support our needs. We got away with a lot because everything was custom, down to the diffing algorithm. This is why I at least started with `alt_registry` to get a feel for what problems we might have. There will likely be some we uncover. I'm fairly confident that we can resolve them in some way,
### Additional information
This is a continuation of the work done in #13980.
While this is noisy and hides other deprecations, I figured deprecations would
make it easier for people to discover what tasks remain and allow us to
divide and conquer this work rather than doing a heroic PR.
In theory, this will be short lived and we'll go back to seeing
deprecations in our tests.
Previously when checking if a dependency is a proc-macro,
the v2 feature resolve resolver v2 looks for `proc-macro = true`
for every target of the dependency.
However, it's impossible to depend on a non-lib target as a proc-macro.
This fix switches to only check if `proc-macro = true` for `[lib]`
target for a dependency.
fix(toml): remove `lib.plugin` key support and make it warning
### What does this PR try to resolve?
Remove `lib.plugin` key, making it an "unused key" warning.
Remove some of the tests, which should look useless (I hope I'm understanding this
- [x] Remove key, and related tests.
- [x] Adjust the documentation about the plugin.
- [ ] Some of the comments and function names have not yet finished being modified.
part of #13629Closes#13246
fix(toml): Convert warnings that `licence` and `readme` files do not exist into errors
### What does this PR try to resolve?
In this PR:
- Changed the warning to a hard error and modified the associated test function;
- Removed what should have been a redundant test function：`publish::publish_with_missing_readme`；
- Since `cargo publish` is preceded by the execution of `cargo package`, the error message in the test `function bad_license_file` needs to be modified.
issue: https://github.com/rust-lang/cargo/issues/13629#license-file-and-readme-pointing-to-a-non-existent-file.
### Additional information
It seems that this is not enough, the current situation is that `cargo package` warns if `package.readme` is an empty string or the wrong file location, but if I cancel `package.readme`, no warning is generated.
I'm wondering if I should judge `package.readme&licence` when executing `cargo package` and return an error if it doesn't exist?
As this has not been done before, your advice is sought.
test(lints): Ensure unused optional dep fires for shadowed dep
This is a way to have an unused optional dependency before 2024 edition.
In prior editions, it is currently a hard error.
I'm tempted to switch that hard error to this lint in prior editions but at minimum, we need to make sure we don't make changes that cause this to revert back to a hard error on 2024+
This is a way to have an unused optional dependency before 2024
edition.
In prior editions, it is currently a hard error.
I'm tempted to switch that hard error to this lint in prior editions
but at minimum, we need to make sure we don't make changes that cause
this to revert back to a hard error on 2024+
Per discussion in https://github.com/rust-lang/cargo/issues/6790. The
--out-dir CLI option and out-dir config option are often confused with
the OUT_DIR environment variable, when the two serve very different
purposes (the former tells Cargo where to copy build artifacts to,
whereas the OUT_DIR environment variable is set *by* Cargo to tell
build scripts where to place their generated intermediate artifacts).
Renaming the option to something less confusing is a prerequisite to
stabilizing it.
