-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Description
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", |
- 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
toTomlWorkspaceDependency
#11409 - Next step:
- Error in 2024 Edition
Independent of Edition
Approved changes
-
plugin
support -
dependency withoutpath
,version
,git
,workspace
specified -
license-file
andreadme
pointing to a non-existent file -
--release
is ignored when paired with--profile
-
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
- 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? ✅
- 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) forreadme
- 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 emptyreadme
orlicense-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
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)
- Deprecation warning using lint system (since restricted
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
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
andcargo 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
- Address warning: skipping duplicate package
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
Metadata
Metadata
Assignees
Labels
Type
Projects
Status