Handle future deprecation annotations #49179
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
That's an excellent idea! All good for me. Anything you see @QuietMisdreavus? |
|
I feel a bit wary about putting something that long in the "short stability notice" on the modules listing, but if you're fine with it i won't block it. Otherwise this looks great, thanks! |
|
I'm open to suggestions if you think the sentence is too long. :) |
|
☔ The latest upstream changes (presumably #48552) made this pull request unmergeable. Please resolve the merge conflicts. |
27730e6 to
101e17d
Compare
|
I struggled a bit coming up with other labels that were shorter, but still readable (and not confusable with items that are currently deprecated: Do you prefer any of these? |
|
Of those, I like "Deprecating in _" the most, partly because the others seem to be more verbose (or are the original, which is fine but long). |
|
@GuillaumeGomez: what do you think about the phrases? |
|
Not native english speaker so I'll trust @QuietMisdreavus on this one. ;) |
|
Okay, I've updated the description to "Deprecating in [version]"! |
|
Your PR failed on Travis. Through arcane magic we have determined that the following fragments from the build log may contain information about the problem. Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
29fb068 to
44ad8fd
Compare
QuietMisdreavus
left a comment
There was a problem hiding this comment.
One last nit, then r=me
src/librustc/middle/stability.rs
Outdated
| // version, then we should display no warning message. | ||
| let deprecated_in_future_version = if let Some(sym) = depr_entry.attr.since { | ||
| let since = sym.as_str(); | ||
| !deprecation_in_effect(since.as_ref()) |
There was a problem hiding this comment.
Please don't use as_ref to get the &str; that tends to be a footgun. Passing &since should cause deref coercion to pass the &str to deprecation_in_effect.
|
@bors: r=QuietMisdreavus,GuillaumeGomez |
|
📌 Commit b2ed9dd has been approved by |
…isdreavus,GuillaumeGomez Handle future deprecation annotations This adds special handling to the `since` parameter of the `deprecated` attribute: in particular, if the `since` version exceeds the version of the compiler, the deprecation notice will not be printed; but a note is added to the documentation stating that the item will be deprecated in a later version. (I've used `since` for this, rather than adding a new attribute, because it's more seamless and, I feel, intuitive. Plus it involves less code churn.)   This is a prerequisite for doing things renaming methods in the standard library (e.g. rust-lang#30459). Resolves rust-lang#30785.
Rollup of 14 pull requests Successful merges: - #49179 (Handle future deprecation annotations ) - #49512 (Add support for variant and types fields for intra links) - #49516 (Add missing anchor for union type fields) - #49532 (Add test for rustdoc ignore test) - #49533 (Add #[must_use] to a few standard library methods) - #49570 (avoid IdxSets containing garbage above the universe length) - #49594 (Add some performance guidance to std::fs and std::io docs) - #49599 (Fix typo) - #49603 (Fix url for intra link provided method) - #49609 (run-pass/attr-stmt-expr: expand test cases) - #49612 (Fix "since" version for getpid feature.) - #49618 (Fix build error when compiling libcore for 16bit targets) - #49619 (tweak core::fmt docs) - #49623 (update mdbook) Failed merges:
…isdreavus,GuillaumeGomez Handle future deprecation annotations This adds special handling to the `since` parameter of the `deprecated` attribute: in particular, if the `since` version exceeds the version of the compiler, the deprecation notice will not be printed; but a note is added to the documentation stating that the item will be deprecated in a later version. (I've used `since` for this, rather than adding a new attribute, because it's more seamless and, I feel, intuitive. Plus it involves less code churn.)   This is a prerequisite for doing things renaming methods in the standard library (e.g. rust-lang#30459). Resolves rust-lang#30785.
Rollup of 25 pull requests Successful merges: - #49179 (Handle future deprecation annotations ) - #49512 (Add support for variant and types fields for intra links) - #49515 (fix targetted value background) - #49516 (Add missing anchor for union type fields) - #49532 (Add test for rustdoc ignore test) - #49533 (Add #[must_use] to a few standard library methods) - #49540 (Fix miri Discriminant() for non-ADT) - #49559 (Introduce Vec::resize_with method (see #41758)) - #49570 (avoid IdxSets containing garbage above the universe length) - #49577 (Stabilize String::replace_range) - #49599 (Fix typo) - #49603 (Fix url for intra link provided method) - #49607 (Stabilize iterator methods in 1.27) - #49609 (run-pass/attr-stmt-expr: expand test cases) - #49612 (Fix "since" version for getpid feature.) - #49618 (Fix build error when compiling libcore for 16bit targets) - #49619 (tweak core::fmt docs) - #49637 (Stabilize parent_id()) - #49639 (Update Cargo) - #49628 (Re-write the documentation index) - #49594 (Add some performance guidance to std::fs and std::io docs) - #49625 (miri: add public alloc_kind accessor) - #49634 (Add a test for the fix to issue #43058) - #49641 (Regression test for #46314) - #49547 (Unignore borrowck test) Failed merges:
…petrochenkov Support future deprecation for rustc_deprecated Follow-up to #49179 to allow `since` parameters to be set to future versions of Rust and correspondingly to not be treated as deprecated until that version. This is required for #30459 to be completed (though we'll need to wait until this hits beta).
This adds special handling to the
sinceparameter of thedeprecatedattribute: in particular, if thesinceversion exceeds the version of the compiler, the deprecation notice will not be printed; but a note is added to the documentation stating that the item will be deprecated in a later version.(I've used
sincefor this, rather than adding a new attribute, because it's more seamless and, I feel, intuitive. Plus it involves less code churn.)This is a prerequisite for doing things renaming methods in the standard library (e.g. #30459). Resolves #30785.