Suggest cargo add when installing library crate
### What does this PR try to resolve?
When using `cargo install` instead of `cargo use` the error message is the following:
```
error: there is nothing to install in `foo v0.0.1`, because it has no binaries
`cargo install` is only for installing programs, and can't be used with libraries.
To use a library crate, add it as a dependency in a Cargo project instead.
```
It would be good to suggest to the user to use `cargo add`.
### How should we test and review this PR?
The `no_binaries` test from `tests/testsuite/install.rs` covers that case.
feat: stabilize auto fix note
A note that some warnings could be fixed by running a `cargo fix` command was added in #10989 and made to work with `clippy` in #11399. It has only been turned on for `nightly` builds so far; this PR would make it show on `stable`.
The original motivation for making this note `nightly` only, was to [allow for iteration](https://github.com/rust-lang/cargo/issues/10976#issuecomment-1289297978) on the message output. There has yet to be any feedback on the message format in the time that it has been on `nightly`. This was brought up in a recent cargo team meeting and it was thought that we should move forward with showing this on `stable`.
close#10976
Ignore `workspace.default-members` when running `cargo install` on root package of a non-virtual workspace
### What does this PR try to resolve?
* Fixes#11058
Two observable behaviors are fixed:
1. When running `cargo install` with `--path` or `--git` and specifically requesting the root package of a non-virtual workspace, `cargo install` will accidentally build `workspace.default-members` instead of the requested root package.
2. Further, if that `default-members` does not include the root package, it will install binaries from those other packages (the `default-members`) and claim they were the binaries from the root package! There is no way, actually, to install the root package binaries.
These two behaviors have the same root cause:
* `cargo install` effectively does `cargo build --release` in the requested package directory, but when this is the root of a non-virtual workspace, that builds `default-members` instead of the requested package.
### How should we test and review this PR?
I have included a test exhibiting this behavior. It currently fails in the manner indicated in the test, and passes with the changes included in this PR.
I'm not sure the solution in the PR is the _best_ solution, but the alternative I am able to come up with involves much more extensive changes to how `cargo install` works, to produce a distinct `CompileOptions` for every package built. I tried to keep the new workspace "API" `ignore_default_members()` as narrowly-scoped in its effect as possible.
### Additional information
The only way I could think this behavior change could impact someone is if they were somehow using `cargo install --path` (or `--git`) and wanting it to actually install the binaries from all of `default-members`. However, I don't believe that's possible, since if there are multiple packages with binaries, I believe cargo requires the packages to be specified. So someone would have to be additionally relying on specifying just the root package, but then wanting the binaries from more than just the root. I think this is probably an acceptable risk for merging!
add newline char to `cargo install .` error message for easier reading.
I just noticed the `cargo install .` error message was not formatted very nicely.
Just added a newline char to make it cleaner.
Thanks
Improve integration of the http server introduced by the http-registry feature.
Now the same HTTP server is used for serving downloads, the index, and
the API.
This makes it easier to write tests that deal with authentication and
http registries.
feat(install): Support `foo@version` like cargo-add
### What does this PR try to resolve?
This aims to make `cargo install` consistent with
- `cargo add foo@version` from #10472
- pkgid changes in #10582
- `cargo yank foo@version` from #10597
It also offers a shorthand for people installing a specific version.
### How should we test and review this PR?
#10582 acted as the FCP for this, see #10597
Documentation updates are split into their own commit to not clog up browsing the code.
Examine the tests to see if they make sense
### Additional information
While the `foo@vewrsion` syntax is the same, each's semantics are different. We had decided it was better to have the same syntax with different semantics than having the user worry about what syntax they use where. In `cargo install`s case, it has an
implicit-but-required `=` operand while `cargo-add` allows any operand.
This doesn't use the full `pkgid` syntax because that allows syntax that
is unsupported here.
This doesn't use `cargo-add`s parser because that is for version reqs.
I held off on reusing the parser from `cargo-yank` because they had
different type system needs and the level of duplication didn't seem
worth it (see Rule of Three).
In #10472, cargo-add was merged with support for an inline version
syntax of `foo@version`. That also served as the change proposal for
extending that syntax to `cargo install` for convinience and consistency.
While both commands are specifying a version-req, `cargo-install` has an
implicit-but-required `=` operand while `cargo-add` allows any operand.
This doesn't use the full `pkgid` syntax because that allows syntax that
is unsupported here.
This doesn't use `cargo-add`s parser because that is for version reqs.
I held off on reusing the parser from `cargo-yank` because they had
different type system needs and the level of duplication didn't seem
worth it (see Rule of Three).
During the design conversations on cargo-add, we noticed that
`cargo-install` has a public flag `--version` and an invisible alias
`--vers` while `cargo-yank` has a public flag `--vers`. This switches
`cargo-yank` to publicly use `--version` and have an invisible alias
`--vers`, making them consistent.
Completions are a best guess.
Inspired by #10345, I looked for other cases where
`toml_edit::easy::to_string` is used (which outputs inline tables) to
see if we should switch to `to_string_pretty`. The crates v1 file was
the only case I found.
As a side effect, we can no longer elide the empty `dev-dependencies`
table in published manifests. This was the behavior before `toml_edit`,
so not much of a loss.
Benefits:
- A TOML 1.0 compliant parser
- Unblock future work
- Have `cargo init` add the current crate to the workspace, rather
than error
- #5586: Upstream `cargo-add`
This works by introspecting rustc's error output, using the JSON format
to determine whether it's a warning or error, then skipping it
altogether if it's a summary of the diagnostics printed.
Before:
```
src/main.rs:1:10: warning: trait objects without an explicit `dyn` are deprecated
src/main.rs:1:1: error[E0601]: `main` function not found in crate `wrong`
src/main.rs:1:9: error[E0038]: the trait `Clone` cannot be made into an object
error: aborting due to 2 previous errors; 1 warning emitted
error: could not compile `wrong`
```
After:
```
$ cargo check --message-format short
src/main.rs:1:10: warning: trait objects without an explicit `dyn` are deprecated
src/main.rs:1:1: error[E0601]: `main` function not found in crate `wrong`
src/main.rs:1:9: error[E0038]: the trait `Clone` cannot be made into an object
error: could not compile `wrong` due to 2 previous errors; 1 warning emitted
```
