Always allow hg to be missing on CI.
`hg` isn't installed on rust-lang/rust Docker images, which causes this check to fail.
Rather than trying to carefully enforce the requirements for `hg` being tested, this just ignores the test if it is unavailable on CI. I think this is something that can be revisited if Cargo ever gains more hg support.
Fix formats_source test requiring rustfmt.
The requirements added in #9892 that `rustfmt` must be present doesn't work in the `rust-lang/rust` environment. There are two issues:
* Cargo is run without using rustup. If you also have rustup installed, the test will fail because the `rustfmt` binary found in `PATH` will fail to choose a toolchain because HOME points to the sandbox home which does not have a rustup configuration.
* rust-lang/rust CI uninstalls rustup, and does not have rustfmt in PATH at all. It is not practical to make rustfmt available there.
The solution here is to just revert the behavior back to where it was where it checks if it can run `rustfmt` in the sandbox. This should work for anyone who has a normal rustup installation (including Cargo's CI). If running the testsuite without rustup, then the test will be skipped.
This also includes a small enhancement to provide better error information when rustfmt fails.
Disable scrape_examples_complex_reverse_dependencies
The test `scrape_examples_complex_reverse_dependencies` no longer works on the latest nightly. It fails with the error:
```
error[E0433]: failed to resolve: could not resolve path `a::f`
--> examples/ex.rs:1:13
|
1 | fn main() { a::f(); }
| ^^^^ could not resolve path `a::f`
|
= note: this error was originally ignored because you are running `rustdoc`
= note: try running again with `rustc` or `cargo check` and you may get a more detailed error
error: Compilation failed, aborting rustdoc
For more information about this error, try `rustc --explain E0433`.
error: could not document `foo`
```
It is not clear to me what this test was trying to exercise, so I'm not sure how to fix it. It has an example that is trying to call a function from a proc-macro, but proc-macros do not export functions.
Disabling for now to get CI passing.
cc `@willcrichton`
Add requirements to cargo_test.
This extends the `#[cargo_test]` attribute to support some additional requirements to control whether or not a test can run. The motivation for this is:
* Can more clearly see when a test is disabled when it prints "ignored"
* Can more easily scan for disabled tests when I do version bumps to see which ones should be enabled on stable (to pass on CI).
The form is a comma separated list of requirements, and if they don't pass the test is ignored. The requirements can be:
* `nightly` — The test only runs on nightly.
* `>=1.55` — The test only runs on rustc with the given version or newer.
* `requires_git` — Requires the given command to be installed. Can be things like `requires_rustfmt` or `requires_hg`, etc.
This also enforces that the author must write a reason why it is ignored (for some of the requirements) so that when I look for tests to update, I know why it is disabled.
This also removes the `CARGO_TEST_DISABLE_GIT_CLI` option, which appears to no longer be necessary since we have migrated to GitHub Actions.
Contrib: Document submodule update process
This adds some contributor documentation on the process I use to update the cargo submodule.
Of course nobody is required to use this process, but I find it works fairly smoothly.
Contrib: Document new-release process
This adds some contributor documentation on the process I use to bump the version and update the changelog. In case I am unavailable to create the changelog, it may perhaps be useful to someone.
Of course nobody is required to use this process, but I find it works fairly smoothly. However, the tool I use is a hacked together script, and may have some hard-coded things, so it may need some work to be useful to others.
Override to resolver=1 in published package
As discussed in #10112 this avoids inconsistent dependency resolution in development and packaged builds when an edition 2021 crate is published from a workspace using the default resolver=1.
fix(add): Update the lock file
This is done in the command, rather than in the op,
- To consistently construct the `Workspace`
- It is more composable as an API
A downside is we update the git dependencies a second time and any sources we didn't initially update.
Unlike the proposal in the attached issue, this does not roll back on error.
- For some errors, the user might want to debug what went wrong. Losing the intermediate state makes that difficult
- Rollback adds its own complications and risks, including since its
non-atomic
We've already tried to address most potential errors during `cargo add`s processing. To meet this desire, we now error if `--locked` is passed in and we would change the manifest. See that individual commit's message for more details.
Fixes#10901
This is done in the command, rather than in the op,
- To consistently construct the `Workspace`
- It is more composable as an API
A downside is we update the git dependencies a second time.
We are not rolling back on error.
- For some errors, the user might want to debug what went wrong
- Rollback adds its own complications and risks, including since its
non-atomic
Fixes#10901
This is prep for #10901 to avoid the most common failure case for the
lock file. We are assuming if the users action caused a change in the
manifes, then it will cause a change in the lock file. This isn't
entirely true but close enough and I think these semantics can make
sense.
Make the empty rustc-wrapper test more explicit.
This changes the test for an empty RUSTC_WRAPPER environment variable to make it explicit that it doesn't just ignore the environment variable, but that it also essentially unsets any config-loaded value. It's not clear if this implication was known at the time it was added in #5985, but I don't think we can change it, and it can be useful.
refactor(source): Open query API for adding more types of queries
### What does this PR try to resolve?
This refactors the Source/Registry traits from accepting a `fuzzy: bool` to accepting an enum so we can add alternative query styles in the future, as discussed in the Cargo team meeting for fixing #10729
The expected fix for `cargo add` at this point would be
- Add `QueryKind::Normalized`
- Initially, we can make it like Exact for path sources and like Fuzzy for registry sources
- Switch cargo-add to using that kind everywhere (both where `Exact` and `Fuzzy` are used)
- A test to ensure this fixed it
- Rename `Fuzzy` to `Alternatives` or something to clarify its actual intent
### How should we test and review this PR?
The refactor is broken down into multiple commits, so ideally review a commit at a time to more easily see how it evolved.
### Additional information
Future possibilities
- Supporting normalized search on all sources
- Doing version / source matching for normalized results (probably not needed for cargo-add but will make the API less surprising for future users)
