diff options
| author | bors <bors@rust-lang.org> | 2021-01-21 09:14:37 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2021-01-21 09:14:37 +0000 |
| commit | 339e19697a39a78f4d669c217b7d21109215de41 (patch) | |
| tree | bf04f4cd2b1c30ca69b7445c8aa3d34999240c30 /compiler/rustc_mir/src/transform/coverage/debug.rs | |
| parent | 57a71ac0e17e4f7070b090ab7bdc5474d8e37ecc (diff) | |
| parent | 6f3df006105ee637f91f0e2af8ecd00c0fda03e6 (diff) | |
| download | rust-339e19697a39a78f4d669c217b7d21109215de41.tar.gz rust-339e19697a39a78f4d669c217b7d21109215de41.zip | |
Auto merge of #80958 - bstrie:deptbdnums, r=KodrAus
Deprecate-in-future the constants superceded by RFC 2700 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 https://github.com/rust-lang/rust/issues/68490#issuecomment-747022696).
Diffstat (limited to 'compiler/rustc_mir/src/transform/coverage/debug.rs')
0 files changed, 0 insertions, 0 deletions