Destabilize RustcEncodable and RustcDecodable #92594

chorman0773 · 2022-01-05T21:35:00Z

This adds the feature rustc_encodable_decodable and gates the previously stable RustcDecodable and RustcEncodable (though deprecated, hidden, and unusable) macros behind them.

These macros have always been a mystery. They have no documentation (and are notably now hidden), cannot be used on stable (except to refer to them, which this PR changes) as their expansion references the rustc_serialize crate (which itself is only exposed as rustc_private), and cannot reasonably be implemented outside of rustc (except as a compile error).
They were deprecated in #83160, but as they cannot be expanded on stable, I see no reason why they cannot be made unstable (or alternatively, removed; I had no issues in rustc itself, from destabilizing the macros, and the only error was in libstd where the macro is reexported in the prelude), however, I would recommend a crater run to be sure (I highly doubt many crates have use core::prelude::v1::RustcDecodable;, though).
See also: https://internals.rust-lang.org/t/what-is-rustc-decodable-encodable-and-why-is-it-stable/13744.

rust-highfive · 2022-01-05T21:35:04Z

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @rust-highfive (or someone else) soon.

Please see the contribution instructions for more information.

chorman0773 · 2022-01-05T21:35:46Z

r? highfive

Mark-Simulacrum · 2022-01-05T21:56:04Z

Is there a reason to feature-gate these vs. just removing them entirely? I believe these are still usable on stable -- the following compiles with rustc-serialize from crates.io in Cargo.toml, for example. So removal/de-stabilization is a breaking change, and I'm not sure if it's warranted.

#[derive(RustcDecodable, RustcEncodable)]
struct Bar {
    f: u32,
}

fn main() {
    println!("{}", rustc_serialize::json::encode(&Bar { f: 3 }).unwrap());
}

chorman0773 · 2022-01-05T22:21:58Z

Is there a reason to feature-gate these vs. just removing them entirely?

I featured gated them for now, but they could be removed entirely instead.

I believe these are still usable on stable -- the following compiles with rustc-serialize from crates.io in Cargo.toml, for example. So removal/de-stabilization is a breaking change, and I'm not sure if it's warranted.

Indeed, which is why I suggested a crater run.
Leaving them in, though, leaves a burden of compatibility, of something entirely unspecified, and highly rustc-specific, for others working on rust implementations (and, arguably, the fact that it does work if you pull in a crate is worse, since it means they can't just be implemented as compile_error!("unsupported"), which is the only logical implementation I can see).

rdrpenguin04 · 2022-01-05T22:26:42Z

By the way, why is Cargo.lock being modified? It doesn't look like anything there is relevant to this PR to me.

Aaron1011 · 2022-01-05T22:31:45Z

There's a disturbingly high number of reverse dependencies on rustc-serialize: from https://crates.io/crates/rustc-serialize/reverse_dependencies, there are 598. I think most of them are optional dependencies behind an off-by-default feature, but it's still bad.

I think this definitely needs a Crater run.

chorman0773 · 2022-01-05T22:36:02Z

By the way, why is Cargo.lock being modified? It doesn't look like anything there is relevant to this PR to me.

I guess because x.py wanted to?

camelid · 2022-01-06T00:28:18Z

src/test/run-make-fulldeps/pretty-expanded/input.rs

-// #13544
+// FIXME: This should be replaced with some other derive macro
+#![feature(rustc_encodable_decodable)]
+#[crate_type="lib"] // Why is this an outer attribute?


Not sure what the comment is about, but this should be:

Suggested change

#[crate_type="lib"] // Why is this an outer attribute?

#![crate_type="lib"]

EDIT: Ah, I see, the attribute was pre-existing. Strange. Not sure what it's for then.

The comment is because the #[crate_type="lib"] line appears in the original version of the test, so I inserted a comment questioning it. It caused my first attempt to fix the test to fail because I saw only the attribute itself and not the relatively insignficant ! when I added the #![feature(rustc_encodale_decodable)] line.

Yeah, it's quite strange. I bet the #[ version of the attribute does nothing, and rustc is just not warning about it.

petrochenkov · 2022-01-06T02:31:42Z

There was already a crater run 2.5 years ago - #62507 (comment).
RustcDecodable caused 418 regressions, and RustcEncodable - 211 regressions.

petrochenkov · 2022-01-06T02:35:52Z

library/core/src/macros/mod.rs

+        feature = "rustc_encodable_decodable",
+        issue = "none",
+        reason = "RustcDecodable cannot be used stably"
+    )]


You can mark both macros as soft-unstable (see macro bench for an example), then the instability will be reported as a deny-by-default lint and won't break other crates depending on crates using these macros.

petrochenkov · 2022-01-06T02:36:42Z

library/core/src/macros/mod.rs

+    #[unstable(
+        feature = "rustc_encodable_decodable",
+        issue = "none",
+        reason = "RustcDecodable cannot be used stably"


Suggested change

reason = "RustcDecodable cannot be used stably"

reason = "unstable implementation detail of the `rustc` compiler, do not use"

petrochenkov · 2022-01-06T02:37:32Z

library/std/src/prelude/v1.rs

@@ -55,7 +55,7 @@ pub use core::prelude::v1::{
 pub use core::prelude::v1::concat_bytes;

 // Do not `doc(inline)` these `doc(hidden)` items.
-#[stable(feature = "builtin_macro_prelude", since = "1.38.0")]
+#[unstable(feature = "rustc_encodable_decodable", issue = "none")]
 #[allow(deprecated)]
 pub use core::prelude::v1::{RustcDecodable, RustcEncodable};


There's a similar reexport in library/core/src/prelude/v1.rs that also needs to be marked as unstable.

Aaron1011 · 2022-01-06T02:44:10Z

I think this would be a good case the the recently-stabilized future-incompat-report future. Getting rustc to emit a report item for just these deprecations will require a few tweaks, though.

petrochenkov · 2022-01-06T02:48:04Z

If this is reported as the SOFT_UNSTABLE lint, then it's already a future-compatibility lint, and no additional action should be necessary.

Aaron1011 · 2022-01-06T02:58:09Z

I was referring to #71249, which will show aessage to downstream crates relying on any of the direct users of these macros.

chorman0773 · 2022-01-06T19:45:14Z

I still would like to see an up-to-date crater run on making it fully-unstable, if possible. Not having an implementation detail of rustc be public and stable at all would be idea, but, if not that, then a deny-by-default fcw would be fair enough. Otherwise, there needs to probably be better documentation of the thing.

Mark-Simulacrum · 2022-01-10T22:33:33Z

Happy to queue up a Crater run on a hard error or deny by default lint -- is that the current state?

I'd personally be fine with an r+ with something that lets dependencies still build -- deny by default lint, for example, seems reasonable.

Mark-Simulacrum · 2022-01-19T15:44:22Z

@craterbot retry

craterbot · 2022-01-19T15:44:24Z

🛠️ Experiment pr-92594 queued again.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2022-01-19T16:10:14Z

🚧 Experiment pr-92594 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

craterbot · 2022-01-20T15:48:00Z

🎉 Experiment pr-92594 is completed!
📊 258 regressed and 3 fixed (205674 total)
📰 Open the full report.

⚠️ If you notice any spurious failure please add them to the blacklist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

nnethercote · 2022-01-23T22:01:53Z

FWIW, I stumbled across these recently and was confused by them. They look like they are defined in core/std, but you have to use rustc_serialize from crates.io for them to work, which is an odd combination. I consider this a minor argument in favour of them going away.

JohnCSimon · 2022-02-13T00:02:12Z

Ping from triage:
@chorman0773 Can you post your status on this PR?

When it's ready for review send a message containing
@rustbot ready to switch to S-waiting-on-review

chorman0773 · 2022-02-13T00:14:55Z

Sorry about that. I got busy with other things. I've grabbed the logs, and want to go through them to see what crates failed, and whether the failures can be fixed. Until that time, it might be best just to proceed as-is, with the deny-by-default, rather than going straight for hard error.

@rustbot ready

Mark-Simulacrum · 2022-02-13T01:32:03Z

src/test/run-make-fulldeps/pretty-expanded/input.rs

-// #13544
+// FIXME: This should be replaced with some other derive macro
+#![feature(rustc_encodable_decodable)]
+#[crate_type="lib"] // Why is this an outer attribute?

 extern crate rustc_serialize;


You can likely swap this test out for derive(Debug) which'll make it simpler and drop the soft-deprecated feature use.

Mark-Simulacrum · 2022-02-13T01:32:55Z

r=me with the PR description updated to reflect soft-deprecation and to avoid misleading commentary about inability to use these on stable.

saethlin · 2022-02-14T18:55:17Z

Of the published crates that this breaks, only 6 have a publication in the last year, and the median publication date is January 2017 (5 years ago). I tossed the list of broken crates from crater into a little script to grab repository links and last publication dates, for anyone who wants to peruse the list: broken-crates.gz

JohnCSimon · 2022-03-20T05:27:59Z

@chorman0773
Ping from triage: Can you please post the status of this PR?

chorman0773 · 2022-03-20T18:31:32Z

Oh sorry, been busy with other projects and haven't had a chance to work on this. I'll look into making the requested fixes in a day or so.

…

On Sun, 20 Mar 2022 at 01:28, John Simon ***@***.***> wrote: @chorman0773 <https://github.com/chorman0773> Ping from triage: Can you please post the status of this PR? — Reply to this email directly, view it on GitHub <#92594 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGLD2ZWXGJL735KDMKOY4LVA2ZOVANCNFSM5LK4SJ5Q> . You are receiving this because you were mentioned.Message ID: ***@***.***>

JohnCSimon · 2022-05-22T03:07:07Z

@saethlin
Ping from triage: I'm closing this due to inactivity, Please reopen when you are ready to continue with this.
Note: if you do please open the PR BEFORE you push to it, else you won't be able to reopen - this is a quirk of github.
Thanks for your contribution.

@rustbot label: +S-inactive

saethlin · 2022-05-22T03:26:15Z

Thanks for the ping but I think you meant @chorman0773

nnethercote · 2024-04-25T08:17:20Z

For posterity: this ended up being done in #116016.

Destabilize RustcEncodable and RustcDecodable

28aa986

rust-highfive self-assigned this Jan 5, 2022

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 5, 2022

Mark-Simulacrum assigned Mark-Simulacrum and unassigned rust-highfive Jan 5, 2022

This comment has been minimized.

Sign in to view

chorman0773 added 2 commits January 5, 2022 17:32

Temporary pretty-expand test fix

cd60be9

Revert Cargo.lock

634346d

This comment has been minimized.

Sign in to view

Fix pretty-expanded/input.rs (again)

c2167cc

petrochenkov self-assigned this Jan 6, 2022

camelid added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Jan 6, 2022

camelid reviewed Jan 6, 2022

View reviewed changes

petrochenkov reviewed Jan 6, 2022

View reviewed changes

petrochenkov removed their assignment Jan 6, 2022

Add soft to unstable

77a0bfa

craterbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-crater Status: Waiting on a crater run to be completed. labels Jan 20, 2022

Mark-Simulacrum added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 21, 2022

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 13, 2022

Mark-Simulacrum reviewed Feb 13, 2022

View reviewed changes

Mark-Simulacrum added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 14, 2022

JohnCSimon added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 11, 2022

JohnCSimon added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels May 8, 2022

JohnCSimon closed this May 22, 2022

rustbot added the S-inactive Status: Inactive and waiting on the author. This is often applied to closed PRs. label May 22, 2022

jhpratt mentioned this pull request Sep 20, 2023

Soft-destabilize RustcEncodable & RustcDecodable, remove from prelude in next edition rust-lang/libs-team#272

Closed

	#[crate_type="lib"] // Why is this an outer attribute?
	#![crate_type="lib"]

	reason = "RustcDecodable cannot be used stably"
	reason = "unstable implementation detail of the `rustc` compiler, do not use"

Destabilize RustcEncodable and RustcDecodable #92594

Destabilize RustcEncodable and RustcDecodable #92594

Conversation

chorman0773 commented Jan 5, 2022 • edited by camelid Loading

rust-highfive commented Jan 5, 2022

chorman0773 commented Jan 5, 2022

Mark-Simulacrum commented Jan 5, 2022

This comment has been minimized.

chorman0773 commented Jan 5, 2022 • edited Loading

rdrpenguin04 commented Jan 5, 2022

Aaron1011 commented Jan 5, 2022

chorman0773 commented Jan 5, 2022

This comment has been minimized.

camelid Jan 6, 2022 • edited Loading

Choose a reason for hiding this comment

chorman0773 Jan 6, 2022

Choose a reason for hiding this comment

camelid Jan 6, 2022

Choose a reason for hiding this comment

petrochenkov commented Jan 6, 2022

petrochenkov Jan 6, 2022

Choose a reason for hiding this comment

petrochenkov Jan 6, 2022

Choose a reason for hiding this comment

petrochenkov Jan 6, 2022

Choose a reason for hiding this comment

Aaron1011 commented Jan 6, 2022

petrochenkov commented Jan 6, 2022

Aaron1011 commented Jan 6, 2022

chorman0773 commented Jan 6, 2022

Mark-Simulacrum commented Jan 10, 2022

Mark-Simulacrum commented Jan 19, 2022

craterbot commented Jan 19, 2022

craterbot commented Jan 19, 2022

craterbot commented Jan 20, 2022

nnethercote commented Jan 23, 2022

JohnCSimon commented Feb 13, 2022

chorman0773 commented Feb 13, 2022

Mark-Simulacrum Feb 13, 2022

Choose a reason for hiding this comment

Mark-Simulacrum commented Feb 13, 2022

saethlin commented Feb 14, 2022

JohnCSimon commented Mar 20, 2022

chorman0773 commented Mar 20, 2022 via email

JohnCSimon commented May 22, 2022

saethlin commented May 22, 2022

nnethercote commented Apr 25, 2024

chorman0773 commented Jan 5, 2022 •

edited by camelid

Loading

chorman0773 commented Jan 5, 2022 •

edited

Loading

camelid Jan 6, 2022 •

edited

Loading