Deprecate-in-future the constants superceded by RFC 2700 #80958
Conversation
|
r? @cramertj (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
The job Click to see the possible cause of the failure (guessed by this bot) |
jyn514
added
the
T-libs-api
|
Nice! I wasn’t aware of @bors r+ |
|
📌 Commit c0c607c has been approved by |
bors
added
S-waiting-on-bors
@KodrAus Well, I only just implemented it. :) I imagine it will be worth keeping in mind for any future deprecation discussions. |
Deprecate-in-future the constants superceded by RFC 2700 Successor to rust-lang#78335, re-opened after addressing the issues tracked in rust-lang#68490. This PR makes use of the new ability to explicitly annotate an item as triggering the deprecated-in-future lint (via `rustc_deprecated(since="TBD"`, see rust-lang#78381). We might call this *soft deprecation*; unlike with deprecation, users will *not* receive warnings when compiling code that uses these items *unless* they opt-in via `#[warn(deprecated_in_future)]`. Like deprecation, soft deprecation causes documentation to formally acknowledge that an item is marked for eventual deprecation (at a non-specific point in the future). With this new ability, we can sidestep all debate about when or on what timeframe something ought to be deprecated; as long as we can agree that something ought to be deprecated, we can receive much of the benefits of deprecation with none of the drawbacks. For these items specifically, the libs team has already agreed that they should be deprecated (see rust-lang#68490 (comment)).
Deprecate-in-future the constants superceded by RFC 2700 Successor to rust-lang#78335, re-opened after addressing the issues tracked in rust-lang#68490. This PR makes use of the new ability to explicitly annotate an item as triggering the deprecated-in-future lint (via `rustc_deprecated(since="TBD"`, see rust-lang#78381). We might call this *soft deprecation*; unlike with deprecation, users will *not* receive warnings when compiling code that uses these items *unless* they opt-in via `#[warn(deprecated_in_future)]`. Like deprecation, soft deprecation causes documentation to formally acknowledge that an item is marked for eventual deprecation (at a non-specific point in the future). With this new ability, we can sidestep all debate about when or on what timeframe something ought to be deprecated; as long as we can agree that something ought to be deprecated, we can receive much of the benefits of deprecation with none of the drawbacks. For these items specifically, the libs team has already agreed that they should be deprecated (see rust-lang#68490 (comment)).
|
Failed in rollup (#80999 (comment)): @bors r- |
bors
added
S-waiting-on-author
|
Removed that |
|
@rustbot modify labels: -S-waiting-on-author +S-waiting-on-review |
rustbot
added
S-waiting-on-review
|
@bors r=KodrAus |
|
📌 Commit 6f3df00 has been approved by |
|
🌲 The tree is currently closed for pull requests below priority 1000. This pull request will be tested once the tree is reopened. |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
@bstrie this caused a relatively small performance regression in the Edit (Mark): we've also noted this for the compiler team in perf nags. |
|
@rylev Regarding code in the compiler, this PR does exactly four things:
The only possible new codepaths that the compiler would execute as a result of this PR would be in code making use of the newly-deprecated items. regex-check is just running |
|
@bstrie I thought that deprecation warnings were opt-in, so would these code paths actually fire on any of these code bases? |
|
@rylev deprecated_in_future is an allow-by-default lint, but that still means that whenever you use a deprecated_in_future item the compiler will need to check if your crate has configured the lint to emit a warning or a denial. Furthermore, the way deprecated_in_future was designed means that for every usage it will check whether or not the current version of the compiler is greater than the I find it unlikely that the deprecation lint specifically could be responsible for any regressions; these are simple checks with no computational complexity, and regex only has like 20 uses of the deprecated constants in the first place (though I didn't check to see if they were in macro expansions). My first instinct would be that something deeper in the lint/attribute machinery is more expensive/heavyweight than expected, but I'm not at all familiar with this part of the compiler. Though if it were a problem with the deprecation lint itself I'd start by investigating the rustc version lookup that happens, since for whatever reason the rustc version appears to be stored in TLS rather than just being a constant string. |
see also #74704 |
|
With regard to the mention of #74704, after some research it appears that there are two kinds of lints in rustc: "built-in" lints that are emitted directly by the compiler, and normal lints that are each implemented as a "pass". #74704 appears to be about skipping certain passes that are known to be disabled. However, I don't know that that approach would suffice to disable "built-in" lints, which is a category that includes deprecated and deprecated_in_future. |
Successor to #78335, re-opened after addressing the issues tracked in #68490.
This PR makes use of the new ability to explicitly annotate an item as triggering the deprecated-in-future lint (via
rustc_deprecated(since="TBD", see #78381). We might call this soft deprecation; unlike with deprecation, users will not receive warnings when compiling code that uses these items unless they opt-in via#[warn(deprecated_in_future)]. Like deprecation, soft deprecation causes documentation to formally acknowledge that an item is marked for eventual deprecation (at a non-specific point in the future).With this new ability, we can sidestep all debate about when or on what timeframe something ought to be deprecated; as long as we can agree that something ought to be deprecated, we can receive much of the benefits of deprecation with none of the drawbacks. For these items specifically, the libs team has already agreed that they should be deprecated (see #68490 (comment)).