RFC: Cargo feature deprecation #3486
Conversation
tgross35
force-pushed
the
feature-deprecation
branch
from
ec49bf1 to
0c803c3
Compare
tgross35
force-pushed
the
feature-deprecation
branch
from
0c803c3 to
6c3d1f4
Compare
compiler-errors
added
the
T-cargo
The hope with these changes is to clarify what is there and not to change what the author intended.
| [rationale-and-alternatives]: #rationale-and-alternatives | ||
|
|
||
| WIP |
There was a problem hiding this comment.
Don't forget to close this out
| [prior-art]: #prior-art | ||
|
|
||
| WIP |
There was a problem hiding this comment.
Don't forget to close this out
| - A `rust-version` field that could indicate e.g. `rust-version = "nightly"` or | ||
| `rust-version = "1.65"` to specify a MSRV for that feature. See: | ||
| <https://github.com/rust-lang/rfcs/pull/3416#discussion_r1174478461> |
There was a problem hiding this comment.
How is this related to deprecation?
| - A `stable` field can be set false to indicate API-unstable or nightly-only | ||
| features (something such as `stable = 3.2` could be used to indicate when a | ||
| feature was stabilized). See also: | ||
| <https://github.com/rust-lang/cargo/issues/10882> |
There was a problem hiding this comment.
How is this connected to this RFC?
| ```toml | ||
| [features] | ||
| foo = { enables = [], deprecated = true } | ||
| foo = { enables = [], deprecated = "this works as a note" } |
There was a problem hiding this comment.
theres two foo features, is that intentional?
epage
added
the
S-waiting-on-author
Co-authored-by: Joe ST <[email protected]>
There was a problem hiding this comment.
Another thought is the (current) inability to squelch the warning. Let's say I update a dependency and start getting the warning, but I can't change it right now. That can be frustrating since you'll get spammed with a warning you can't do anything about every time you run cargo. For normal deprecations, you have the ability to #[allow] it, but without the ability to control cargo's warnings in cargo (cargo#12235), there's nothing you can do.
|
|
||
| [index changes]: #index-changes | ||
|
|
||
| The infromation provided by `deprecated` needs to be stored in the index, and |
There was a problem hiding this comment.
This section contradicts the sentence above that says the information will not be in the index. It's not clear why this is suggesting it should be in the index. Offhand I don't know why this would be added, since I don't think the resolver needs to know this.
| attribute in Rust source. The value can be a boolean, string, or an object with | ||
| `since` or `note` keys. Schema rules are as follows: | ||
|
|
||
| - If a boolean value, `false` indicates not deprecated and `true` indicates |
There was a problem hiding this comment.
It's not clear to me what the benefit is of having a boolean form. deprecated=true provides little information to the user, and it seems relatively little effort to at least provide a string explaining why it is deprecated or what to use instead.
There was a problem hiding this comment.
I assume its to be consistent with the attribute but I see little lost in being inconsistent on this part.
| string was specified in the `note` field (e.g. `foo = { deprecated = { note = "my msg" } }`) | ||
| - If not specified, the default is `false` | ||
|
|
||
| If a downstream crate attempts to use a feature marked `deprecated`, Cargo |
There was a problem hiding this comment.
I would like to see some clarity around the transitive behavior. I would expect transitive warnings to be hidden (like #[deprecated] due to cap-lints), and only show usage of deprecated features from dependency declarations in the local package, or the command-line (x/y style).
And a related thing, if I do --features foo where foo is deprecated in the local package, does that show a warning?
This problem and anoth'r possible solution is hinted at in the |
Rendered
RFC for
feature-deprecationRFC goals: add a way to deprecate Cargo features
This was split from #3416
This would resolve rust-lang/cargo#7130