Next step for deprecations in Cargo

[weihanglo]

2024 Deprecations

Problem

Cargo has been emitting a bunch deprecation message for a (long?) while. Since edition 2024 is approaching (1.82.0 anticipated), and a Cargo linting system is on the way (#13621), we might want to take advantage of this timing to evaluate whether this deprecations could be turned into a hard error.

The main risk here is CI automation might fail. Unlike rustc and clippy lints, people hardly noticed Cargo warnings becuase because there was no way to set -D on them.

Deprecations

2024 Edition

These are being tracked in rust-lang/rust#123754

Details

dev_dependencies/build_dependencies/default_features/crate_types/proc_macro

cargo/src/cargo/util/toml/mod.rs

Lines 198 to 199 in f0ae765

	"conflicting between `{new_path}` and `{old_path}` in the `{name}` {kind}.\n
	`{old_path}` is ignored and not recommended for use in the future"

• Warn since: 1.61 (2022-05-19) but only when conflicting with dash ones
• may become a hard error? NO
• Risk: Old crates fail to compile. Might need an edition boundary.
• Warning on conflicting keys #10316
• Next step:
  • Error on 2024 edition

good old [project] (replaced with [package])

cargo/src/cargo/util/toml/mod.rs

Lines 497 to 498 in f0ae765

	"manifest at `{}` contains both `project` and `package`, \
	this could become a hard error in the future",

• Warn since: 1.66 (2022-12-15)
• may become a hard error? ✅
• Risk: Old crates fail to compile. Require an edition boundary.
• Reduce references to [project] within cargo #11135
• Next step:
  • Error on 2024 edition

default-features in inherited dependencies

cargo/src/cargo/util/toml/mod.rs

Lines 1801 to 1803 in f0ae765

	"`default-features` is ignored for {label}, since `default-features` was \
	{ws_def_feat} for `workspace.dependencies.{label}`, \
	this could become a hard error in the future"

• Warn since: 1.69.0 (2023-04-29)
• may become a hard error? ✅
• Risk: Build failures. Easy to fix.
• fix(toml): Add default-features to TomlWorkspaceDependency #11409
• Next step:
  • Error in 2024 Edition

Independent of Edition

Approved changes

• plugin support
  • see fix(toml): remove lib.plugin key support and make it warning #13902
• dependency without path, version, git, workspace specified
  • see fix(toml)!: Disallow source-less dependencies #13775
• license-file and readme pointing to a non-existent file
  • see fix(toml): Convert warnings that licence and readme files do not exist into errors #13921
• --release is ignored when paired with --profile
  • see fix: using --release/debug and --profile together becomes an error #13971
• cargo read-manifest

Proposed changes

• [replace] is deprecated
• old cargo tree flags
• path override modifying dependency graph
• rustc-cdylib-link-arg used in non-cdylib target
• user-defined alias is shadowing an external subcommand found
• output artifact name collisions
• Bail out when trying to link to a library that is not linkable
• Ambiguous package name in git dependency

plugin support

cargo/src/cargo/util/toml/targets.rs

Lines 211 to 216 in f0ae765

	"support for rustc plugins has been removed from rustc. \
	library `{}` should not specify `plugin = true`",
	name_or_panic(lib)
	));
	warnings.push(format!(
	"support for `plugin = true` will be removed from cargo in the future"

• Warn since: 1.77.0 (2024-03-21)
• may become a hard error? ✅ (stop supporting plugin)
• Risk: Too new.
• Deprecate rustc plugin support in cargo #13248
• fix(toml): remove lib.plugin key support and make it warning #13902
• Next step:
  • Remove key, making it an "unused key" warning

dependency without path, version, git, workspace specified

cargo/src/cargo/util/toml/mod.rs

Lines 1914 to 1918 in 8bcecfe

	"dependency ({}) specified without \
	providing a local path, Git repository, version, or \
	workspace dependency to use. This will be considered an \
	error in future versions",
	name_in_toml

• Warn since: Merged on 2016-01-20
• May become a hard error? ✅
  • Was this a bug?
    • Yes
    • https://github.com/rust-lang/cargo/issues2147#issuecomment-156879677
• Risk: Old crates and deps fail to build. See bit-set 0.2.0's Cargo.toml no longer accepted #9885
• Emit a warning when manifest specifies empty dependency constraints #2270
• Next step:
  • Hard error, see fix(toml)!: Disallow source-less dependencies #13775

Note:

• this affects [dependencies] as well as [patch], [replace], including in virtual workspaces and config where Editions don't apply
• hard error makes the format more future proof for adding additional sources (otherwise old cargos would do wildly bad things)

license-file and readme pointing to a non-existent file

cargo/src/cargo/ops/cargo_package.rs

Lines 416 to 418 in f0ae765

	"{manifest_key_name} `{}` does not appear to exist{}.\n\
	Please update the {manifest_key_name} setting in the manifest at `{}`\n\
	This may become a hard error in the future.",

• Warn since: 1.43.0 (2020-04-23) for license-file; 1.71.0 (2023-08-03) for readme
• may become a hard error? ✅ )
• Risk: Publish might fail. Easy to fix in normal cases.
• Better support for license-file. #7905
• Warn instead of error in cargo package on empty readme or license-file in manifest #12036
• Next step:
  • Hard error, even for empty string

--release is ignored when paired with --profile

cargo/src/cargo/util/command_prelude.rs

Lines 570 to 573 in 8bcecfe

	"the `--release` flag should not be specified with the `--profile` flag\n\
	The `--release` flag will be ignored.\n\
	This was historically accepted, but will become an error \
	in a future release."

• Warn since: 1.57.0 (2021-12-02)
• may become a hard error? ✅
• Risk: Break people's build. Easy to fix by themselves.
• Stabilize named profiles #9943
• Next step:
  • Hard error

cargo read-manifest

cargo/src/bin/cargo/commands/read_manifest.rs

Line 9 in 8bcecfe

Deprecated, use `<cyan,bold>cargo metadata --no-deps</>` instead.\

• Warn since: Merged on 2016-10-03.
• Become a hard error? NO
• Risk: Automations might still rely on it. cargo metadata --no-deps should cover its use cases.
• Document that read_manifest command is deprecated #3150
• Next step:
  • Needs further investigation (unclear why this was deprecated and if it still fills a unique niche)

[replace] is deprecated

cargo/src/doc/src/reference/overriding-dependencies.md

Lines 300 to 301 in 8bcecfe

	> **Note**: `[replace]` is deprecated. You should use the
	> [`[patch]`](#the-patch-section) table instead.

• Warn since: 1.42.0 (2020-03-12)
• may become a hard error? NO
• Risk: Can we patch [patch] to fully replace [repalce]?
• Various doc updates #7733
• Next step (proposed)
  • Deprecation warning using lint system (since restricted Carog.toml)
  • Maybe with future edition turn it into forbid (based on people's reaction to warning)

old cargo tree flags: --all, no-dev-dependencies, --no-indent, --prefix-depth, --all-targets

cargo/src/bin/cargo/commands/tree.rs

Lines 144 to 146 in 8bcecfe

	"The `cargo tree` --all flag has been changed to --no-dedupe, \
	and may be removed in a future version.\n\
	If you are looking to display all workspace members, use the --workspace flag.",

• Warn since: 1.44.0 (2020-06-04)
• may become a hard error? ✅ for all; NO for others
• Risk: Have alternatives. Easy to fix.
• Add backwards-compatibility for old cargo-tree flags. #8115
• Next step (proposed):
  • Downgrade to consistent deprecation (no point removing one when others would be kept)

path override modifying dependency graph

cargo/src/cargo/core/registry.rs

Lines 535 to 538 in f0ae765

	This is currently allowed but is known to produce buggy behavior with spurious
	recompiles and changes to the crate graph. Path overrides unfortunately were
	never intended to support this feature, so for now this message is just a
	warning. In the future, however, this message will become a hard error.

• Warn since: Merged on 2016-10-05 (1.14 or so)
• may become a hard error? ✅ (was a bug)
• Risk: Assuming people seldom use it?
• Warn about path overrides that won't work #3136
• Next step (proposed):
  • Turn into error because it was a bug with buggy behavior and people using this went into it knowing its bad (since they likely started post-1.14), and we've not been getting necro-posts for people saying they need this (like depending on bins)

rustc-cdylib-link-arg used in non-cdylib target

cargo/src/cargo/core/compiler/custom_build.rs

Lines 850 to 856 in f0ae765

	"{}{} was specified in the build script of {}, \
	but that package does not contain a cdylib target\n\
	\n\
	Allowing this was an unintended change in the 1.50 \
	release, and may become an error in the future. \
	For more information, see \
	<https://github.com/rust-lang/cargo/issues/9562>.",

• Warn since: 1.54.0 (2021-07-29)
• may become a hard error? ✅ (may become)
• Risk: crates might depends on this heavily; might need a way to toggle like Managing the propagation of features across a large workspace is infeasible without tooling support #9094 or Pre-RFC for mutually-exclusive, global features
• Change rustc-cdylib-link-arg error to a warning. #9563
• Next step (proposed):
  • Hard error, independent of edition, because this was never intended, we warning for a while, and no has brought up a concrete case of the warning firing when they need it

user-defined alias is shadowing an external subcommand found

cargo/src/bin/cargo/cli.rs

Lines 321 to 323 in f0ae765

	user-defined alias `{}` is shadowing an external subcommand found at: `{}`
	This was previously accepted but is being phased out; it will become a hard error in a future release.
	For more information, see issue #10049 <https://github.com/rust-lang/cargo/issues/10049>.",

• Warn since: 1.58.0 (2022-01-13)
• may become a hard error? ✅
• Risk: Custom workflow might fail. cargo clippy and cargo fmt are what we concerned.
• Aliases should not be able to shadow external subcommands #10049
• Warn when alias shadows external subcommand #10082
• Next step (proposed):
  • Turn into hard error. Aliases are generally for user interaction, rather than automation (except for things like xtasks) so the impact is low

output artifact name collisions

cargo/src/cargo/core/compiler/build_runner/mod.rs

Lines 472 to 474 in f0ae765

	"Consider changing their names to be unique or compiling them separately.\n\
	This may become a hard error in the future; see \
	<https://github.com/rust-lang/cargo/issues/6313>.";

• Warn since: 1.32.0 (2019-01-17)
• may become a hard error? ✅
• Risk: Workaround could be quite complicated.
• Check for duplicate output filenames. #6308
• Next step (proposed):
  • Maybe in a future Edition, switch to forbid by default?
  • Or just warn because this is implementation-defined for when a collision may occur and new collisions may come up in the future

Bail out when trying to link to a library that is not linkable

cargo/src/cargo/core/compiler/mod.rs

Lines 1427 to 1430 in f0ae765

	"The package `{}` \
	provides no linkable target. The compiler might raise an error while compiling \
	`{}`. Consider adding 'dylib' or 'rlib' to key `crate-type` in `{}`'s \
	Cargo.toml. This warning might turn into a hard error in the future.",

• Warn since: 1.24.0 (2018-02-15)
• may become a hard error? ✅
• Risk: People depend on this in a quirky way.
• Bail out when trying to link to a library that is not linkable. #4797
• Next step (proposed):
  • Needs investigation into replacement feature for those relying on it
  • Likely should instead be hard error conditioned on Edition

Ambiguous package name in git dependency

cargo/src/cargo/ops/cargo_read_manifest.rs

Lines 225 to 234 in bd1cf58

	// We can assume a package with publish = false isn't intended to be seen
	// by users so we can hide the warning about those since the user is unlikely
	// to care about those cases.
	if pkg.publish().is_none() {
	let _ = gctx.shell().warn(format!(
	"skipping duplicate package `{}` found at `{}`",
	pkg.name(),
	path.display()
	));
	}

• Warn since: 1.63
• may become a hard error? NO
• Risk: too many false positives, see warning: skipping duplicate package case found at ~\.cargo\git\checkouts\cargo-.. #10752
• Emit warning upon encountering multiple packages with the same name #10701, Restrict duplicate deps warning only to published packages #10767
• Next step (proposed):
  • Address warning: skipping duplicate package case found at ~\.cargo\git\checkouts\cargo-.. #10752
  • Turn into error on edition

No further steps

deprecate --all (alias to --workspace)

cargo/src/cargo/util/command_prelude.rs

Line 54 in 8bcecfe

flag("all", "Alias for --workspace (deprecated)")

• Warn since: 1.39.0 (2019-11-07)
• may become a hard error? NO
• Risk: Automations might still rely on it. Some users use it exclusively due to brevity (see also Add short flag -w for --workspace #11554)
• Rename --all to --workspace #7241
• Next step (proposed):
  • CLI, so no further steps
  • Not doing runtime warning because of pervasive use by people who really like it for brevity

Deprecate .cargo/config

cargo/src/cargo/util/context/mod.rs

Lines 1563 to 1567 in 8bcecfe

	"`{}` is deprecated in favor of `{filename_without_extension}.toml`",
	possible.display(),
	))?;
	self.shell().note(
	format!("if you need to support cargo 1.38 or earlier, you can symlink `{filename_without_extension}` to `{filename_without_extension}.toml`"),

• Warn since: 1.78 (2024-05-02)
• may become a hard error? NO
• Risk: Way too new.
• fix(config): Deprecate non-extension files  #13349
• Next step (proposed):
  • No further steps

[epage]

dependency without path, version, git, workspace specified

While it says it may transition to a hard error, the fact that issues seemed to exist where we broke people previously for this makes me cautious about doing it.

I'm at least for making this an error on the next Edition.

cargo read-manifest

As this is a command, I don't think there are further next steps.

At most, we could check the Edition and hard error but that seems unnecessary.

We could hide it in cargo --list but its good for people to know what built-ins exist because of how conflicts work with commands.

path override modifying dependency graph

I don't have a good feel for this for turning

Bail out when trying to link to a library that is not linkable

I feel like this is blocked on issues like #7825

output artifact name collisions

Is this blocked on #8794?

deprecate --all (alias to --workspace)

We should remove this from -h.

Otherwise, as a CLI, there isn't much more we should do.

[replace] is deprecated

Being config, I'm not sure there is much we should do.

license-file and readme pointing to a non-existent file

At one point, this was an error. I wonder if we were too aggressive in making this a warning.

Maybe if the fields are empty, we allow it but otherwise go ahead and error?

old cargo tree flags: --all, no-dev-dependencies, --no-indent, --prefix-depth, --all-targets

Being a CLI, is there much we should do?

rustc-cdylib-link-arg used in non-cdylib target

I'm for a hard error. The message says this wasn't originally allowed and that it was a bug that it was allowed.

--release is ignored when paired with --profile

Despite being in the CLI, I'm somewhat tempted to allow this to error.

user-defined alias is shadowing an external subcommand found:

Despite being a mixture of CLI and config, I'm game for this. Generally aliases are for users and not automation. xtasks are an exception but a well structured pattern of it.

dev_dependencies/build_dependencies/default_features/crate_types/proc_macro

Error on next edition

good old [project] (replaced with [package])

Without more historical context for why it should unconditionally error, I'd say error on next edition

default-features in inherited dependencies

Error on next edition

plugin support

Remove

Deprecate .cargo/config

Keep as-is (deprecated). Being config, we can't use Editions. Its also likely something tied to automation, so we can't remove either.

[epage]

We discussed some of these in today's team meeting and updated the next steps for those items. For things that weren't discussed I noted that the "Next Steps" are "proposed".