about summary refs log tree commit diff
path: root/compiler/rustc_llvm/llvm-wrapper/CoverageMappingWrapper.cpp
diff options
context:
space:
mode:
authorbors <bors@rust-lang.org>2021-01-21 09:14:37 +0000
committerbors <bors@rust-lang.org>2021-01-21 09:14:37 +0000
commit339e19697a39a78f4d669c217b7d21109215de41 (patch)
treebf04f4cd2b1c30ca69b7445c8aa3d34999240c30 /compiler/rustc_llvm/llvm-wrapper/CoverageMappingWrapper.cpp
parent57a71ac0e17e4f7070b090ab7bdc5474d8e37ecc (diff)
parent6f3df006105ee637f91f0e2af8ecd00c0fda03e6 (diff)
downloadrust-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_llvm/llvm-wrapper/CoverageMappingWrapper.cpp')
0 files changed, 0 insertions, 0 deletions