`cargo update --precise` without `-p` flag silently succeeds and runs `cargo update`

[lopopolo]

Problem

I tried to use cargo update with the --precise flag to downgrade a dependency without reading the docs.

I tried:

$ cargo update --precise chrono-tz@0.6.1
    Updating crates.io index

This succeeded with no error and did not do what I expected.

The docs mention that --precise is meant to be combined with the -p flag:

When used with -p, allows you to specify a specific version number to set the package to. If the package comes from a git repository, this can be a git revision (such as a SHA hash or tag).

Steps

run cargo update --precise chrono-tz@0.6.1

Possible Solution(s)

The docs mention that --precise is meant to be combined with the -p flag. If --precise is given without -p, I think this should be an error.

Notes

No response

Version

cargo 1.62.1 (a748cf5a3 2022-06-08)
release: 1.62.1
commit-hash: a748cf5a3e666bc2dcdf54f37adef8ef22196452
commit-date: 2022-06-08
host: x86_64-apple-darwin
libgit2: 1.4.2 (sys:0.14.2 vendored)
libcurl: 7.79.1 (sys:0.4.51+curl-7.80.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
os: Mac OS 12.5.0 [64-bit]

[epage]

I'm assuming we'd want to declare the precise argument to requires("package") in clap. While that would be taking a non-error case to an error case, it seems unlikely that someone would be relying on this behavior since its ignored.

[weihanglo]

I'd suggest starting a transition period that warns users it's ignored. Steps to fix might like:

1. When --precise or --aggressive is present but zero -package given, emit a warning inside update_lockfile(). Tell user that the old behaivour of missing -p that acts as cargo update is deprecated and will soon become a hard error.
2. Turn it into hard error once the warning hits stable Rust release. That is, the transition period would be three months.
3. In addition, leverage clap's requires to enforce the hard requirement relationship as epage suggested.

[0xPoe]

@rustbot claim