Skip to content

Next step for deprecations in Cargo #13629

New issue
Jump to bottom
New issue
Jump to bottom
Open
Open
Next step for deprecations in Cargo#13629
Labels
A-cliArea: Command-line interface, option parsing, etc.A-edition-nextArea: may require a breaking change over an editionA-manifestArea: Cargo.toml issuesC-cleanupCategory: cleanup within the codebaseS-acceptedStatus: Issue or feature is accepted, and has a team member available to help mentor or review
@weihanglo

Description

@weihanglo
weihanglo
opened on Mar 22, 2024

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

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",

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"

Independent of Edition

Approved changes

Proposed changes

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"

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

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.",

--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.",

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>.",

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>.",

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.",

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()
));
}

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`"),

Metadata

Assignees

No one assigned

    Labels

    A-cliArea: Command-line interface, option parsing, etc.A-edition-nextArea: may require a breaking change over an editionA-manifestArea: Cargo.toml issuesC-cleanupCategory: cleanup within the codebaseS-acceptedStatus: Issue or feature is accepted, and has a team member available to help mentor or review

    Type

    No type

    Projects

    Cargo Edition 2024 Planning

    • Status

      No status

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions