Commit graph

192 commits

Author SHA1 Message Date
Weihang Lo
f9fd4ff4ee
fix(json-msg): use pkgid spec in in JSON messages
In 12914 we stabilized pkgid spec as unique package identifier for
`cargo metadata`. However, we forgot to make the same change to
JSON message format[^1]. This PR does so.

Note that the `package_id` field in JSON message is not clearly stated
as "opaque", so it might be considered as a breaking change to some extent.

[^1]: https://doc.rust-lang.org/nightly/cargo/reference/external-tools.html#compiler-messages
2024-01-17 11:31:19 -05:00
Scott Schafer
0d62ae2fc3
feat: Add rustc style errors for manifest parsing 2023-12-15 13:30:10 -07:00
Weihang Lo
48cffc6729
fix(cargo-install): clarify --path is installation source 2023-12-26 10:42:57 -05:00
Weihang Lo
297b827fa3
test(install): use TCP connection instead of thread sleep
This is more robust than `thread::sleep`, ensuring

* foo is running before the first `cargo uninstall` call
* foo is stopped before the second `cargo uninstall` call
2023-12-02 01:54:20 -05:00
bors
847958971b Auto merge of #13053 - linyihai:cargo-uninstall-fixed, r=weihanglo
Fixed uninstall a running binary failed on Windows

### What does this PR try to resolve?
 Fixes https://github.com/rust-lang/cargo/issues/3364

The problem reproduce when you try to uninstall a running binary and it will failed on Windows,  this is because that cargo had already remove the installed binary tracker information in disk,  and next to remove the running binary but it is not allowed in Windows.  And to the worst,  you can not uninstall the binary already and only to reinstall it by the `--force` flag.

### How to solve the issue?
This PR try to make the uninstall a binary more reasonable that  only after remove the binary sucessfully then remove the tracker information on binary and make the remove binary one by one.

### How should we test and review this PR?
Add testcase 0fd4fd357b
- install the `foo`
- run `foo` in another thread.
- try to uninstall running `foo` and only failed in Windows.
- wait the `foo` finish, uninstall `foo`
- install the `foo`

### Additional information
2023-12-01 15:10:56 +00:00
Lin Yihai
db144c9d0a Add tracker verification for test case uninstall_running_binary 2023-12-01 22:23:40 +08:00
Lin Yihai
1e3b4231da chore: fixed clippy 2023-11-30 15:46:02 +08:00
Adrian
b7b5a093a1
Fix cargo errors counter 2023-11-29 18:47:14 +02:00
Lin Yihai
0fd4fd357b Add test case for cargo uninstall while try to uninstalling a running Bin. 2023-11-29 17:52:22 +08:00
hi-rustin
731ae05ae3 Dedup the same version binaries
Signed-off-by: hi-rustin <rustin.liu@gmail.com>
2023-10-27 09:16:18 +08:00
hi-rustin
397f446dcd Add test for installing the same binary twice
Signed-off-by: hi-rustin <rustin.liu@gmail.com>
2023-10-27 09:16:12 +08:00
Ed Page
5f0596941f fix(help): Clarify install's positional
- That a version is accepted
- That you are selecting from the source a package which led to part of
  the confusion in #4830

I wonder if we should rename our `CRATE` value names to `PKG`/`PACKAGE`
2023-10-17 16:48:15 -05:00
Ed Page
99f917a67e fix(help): Consistently use SCREAMING_CASE for value names
- We have some positional value names that are SCREAMING_CASE and some
  that aren't
- All of the value names for our flags are already SCREAMING_CASE
2023-10-17 16:47:44 -05:00
Ed Page
9b32be7f89 fix(install): Suggest an alternative version on MSRV failure
The next step would be to also automatically install an MSRV compatible
version if compatible with the version req (#10903).
This improved error message will still be useful if the MSRV compatible
version is outside of the version req.

I did this as the first step
- Helps people now, not needing to wait on `-Zmsrv-policy` to be stabilized
- Has fewer questions on how it should be done (or if it should be)
2023-10-09 20:22:54 -05:00
Ed Page
2976e2ac66 fix(install): Don't suggest --locked for MSRV when its root package
This will also report the error without having to download the `.crate`
first.

If installing multiple packages, this will also report it immediately,
rather than waiting for the other packages to be installed first.

This also offers us more flexibility in the error we report,
like suggesting more appropriate fixes.
2023-10-09 16:31:30 -05:00
Ed Page
699b30a5f4 test(install): Verify existing top-level MSRV behavior 2023-10-09 15:48:53 -05:00
hi-rustin
97656fbf87 Correct the helper name and the tip message 2023-09-21 10:12:03 +08:00
hi-rustin
817c2cbbb5 Better suggestion for unsupported mode in install command 2023-09-20 11:31:36 +08:00
hi-rustin
7644a4bd96 Add test for using unsupported mode in install command 2023-09-20 11:27:56 +08:00
Jacob Finkelman
44666f7377 Ues strip_prefix for cleaner code 2023-09-07 17:57:28 +00:00
Matheus Cardoso
ecf05e4ff1
cargo install: suggest --git when package name is url 2023-08-27 23:04:21 -03:00
Ed Page
937932520b refactor(install): Move version parsing to the CLI 2023-08-23 16:22:31 -05:00
Ed Page
28b7c846af refactor(install): Shift crate argument parsing to clap 2023-08-23 15:25:05 -05:00
Weihang Lo
b9e70ec0a2
test: relax assertions of panic handler message format 2023-07-29 17:12:46 +01:00
MarcusGrass
03675ef6a4
Add additional info on a new line 2023-06-05 11:27:31 +02:00
MarcusGrass
073a32b61f
Add message on reusing previous temporary path on failed cargo installs 2023-06-04 18:31:06 +02:00
Danil Hendra Suryawan
58b7bce63e feat(cli): emit error when install is given a toolchain name instead of crate name 2023-06-03 20:51:14 +07:00
Weihang Lo
7fb35c9c4e
test(install): correct the term workspace -> local packagd 2023-05-03 01:04:18 +01:00
Ted Kaminski
79bb2d7143 Update pkg-spec comment, and add 2 more test cases 2023-05-01 17:23:17 -05:00
Ted Kaminski
31d679e81a Build by PackageIdSpec, not name, to avoid ambiguity 2023-05-01 17:23:17 -05:00
Dom Slee
3363931f7f redundant escapes 2023-03-13 18:57:26 +11:00
Dom Slee
ea27499a2e review comments 2023-03-13 17:54:45 +11:00
Dom Slee
dc449bce6d cargo clippy + fmt 2023-03-12 23:52:45 +11:00
Dom Slee
a668956dd7 improve error message and add related tests 2023-03-12 23:52:06 +11:00
Adrián Ortiz
db457d950f Fixing issue https://github.com/rust-lang/cargo/issues/10834:
- Adding display of which target failed to compile
- Consistent messages for warnings/errors.
- Fixing assertions on related tests.
2023-03-07 06:45:26 +01:00
Eric Huss
ab726e7e7f Fix test for Windows 2023-02-25 18:07:49 -08:00
Arlo Siemsen
16ad1f2945 Fix Cargo removing the sparse+ prefix from sparse URLs in .crates.toml 2023-02-25 18:07:46 -08:00
Eric Huss
736fb2f62a Fix warning with tempfile 2023-02-25 15:35:12 -08:00
bors
0625b29d84 Auto merge of #11410 - TrAyZeN:master, r=epage
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.
2023-02-23 18:44:31 +00:00
TrAyZeN
98edd706ad Suggest cargo add when installing library crate 2023-02-18 17:39:11 +01:00
Ed Page
6007f05a85 chore: Update to toml v0.6, toml_edit v0.18
`toml` replaces `toml_edit::easy`, using `toml_edit` as its parser.
2023-01-19 15:26:28 -06:00
bors
6c095cce88 Auto merge of #11558 - Muscraft:stabilize-cargo-fix-message, r=epage
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
2023-01-22 00:50:42 +00:00
bors
23424fde2e Auto merge of #11067 - tedinski:install_workspace_root, r=weihanglo
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!
2023-01-18 15:47:10 +00:00
Weihang Lo
c51c6bb6ac
chore: reflect to clap updates 2023-01-14 09:23:39 +00:00
Ted Kaminski
7dc8be5414 Ignore workspace.default-members when running cargo install on root package of a non-virtual workspace 2023-01-13 00:12:06 +00:00
Scott Schafer
6131222ba2 feat: stabilize auto fix note 2023-01-10 13:52:29 -06:00
bors
79fe7573b0 Auto merge of #11401 - adam248:patch-1, r=ehuss
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
2022-11-25 13:34:10 +00:00
Adam Butler
1b7e256413 fixed typo causing broken cargo install . test case 2022-11-22 14:14:29 +09:30
Adam Butler
db0d3f9de1
fixed cargo fmt error regarding unknown escape char. 2022-11-22 13:24:59 +09:30
Adam Butler
c5836e97ba
fixed broken error made by newline char in cargo install . error message 2022-11-22 13:19:05 +09:30