make rustc_encodable_decodable feature properly unstable

[RalfJung]

This has been shown in future-compat reports since Rust 1.79 (#116016), released June 2024. Let's see if crater still finds any issues.

Part of #134301.

Cc @rust-lang/libs-api

[rustbot]

r? @ibraheemdev

rustbot has assigned @ibraheemdev.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[RalfJung]

Hm, seeing the discussion in #116016 it seems like the plan was to move much more slowly with this? There's no separate tracking issue for the de-stabilization of this as far as I can see, so it's all a bit unclear.

I guess we'll see what crater says.
@bors try

[bors]

⌛ Trying commit 3ce5d1d with merge 79200d6...

[RalfJung]

@bors try

[bors]

⌛ Trying commit 88960fd with merge 09ea730...

[bors]

☀️ Try build successful - checks-actions
Build commit: 09ea730 (09ea730c380b8b9acb96ff87b724c45df920f793)

[RalfJung]

@craterbot check

[craterbot]

👌 Experiment pr-134272 created and queued.
🤖 Automatically detected try build 09ea730
🔍 You can check out the queue and this experiment's details.

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

[jhpratt]

I don't think there really was a plan — soft destabilizing it was the extent to which it was discussed afaik.

[RalfJung]

There's some mixed messaging here: the ACP says "full destabilization is not proposed due to breakage of existing code", but the lint that is emitted when using these types says this "will become a hard error in a future release".

[jhpratt]

Ha, that's 100% on me. It must have been discussed on Zulip, as I wasn't aware soft destabilization was a thing before that. Anyways, it doesn't much matter.

[RalfJung]

Well, seems like nobody complained about the future compat "this will become a hard error" warning that we have emitted for more than half a year now (and that is shown even when this occurs just in a dependency), so let's just see what crater says.

[craterbot]

🚧 Experiment pr-134272 is now running

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

[craterbot]

🎉 Experiment pr-134272 is completed!
📊 286 regressed and 48 fixed (553892 total)
📰 Open the full report.

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

[Skgland]

Analysis the regressed results with https://github.com/Skgland/Crater-Analysis yields:

139 times error[E0658]: use of unstable library feature `rustc_encodable_decodable`
121 times no space left on device
21 times collect2: fatal error: ld terminated with signal 7 [Bus error]

And five other

• "indutny.bulk-gcd.59c6117a35e323b1cd959c6cac3596f703669e65"
• "jakubo87.heal.0fbe28eb6adc85f22a278d0bb87026553de9dbbd"
• "noorulislam770.rust-std-lib.f8087a3d86cb559a3c3c2d1e6bd8338b60b6fd28"
• "tomshlomo.json-unix-time-staging.1d750b8553cafc1d4c3c233207a80c8e1c53af6b"
• "xswordsx.ff.2e9778658b16c72d5516cea04da3a9b8b0eea557"

[RalfJung]

I've done an in-depth analysis of the crates.io failures at https://hackmd.io/@RalfJung/HyXfMpGH1e. (I did not look at the github repo failures.) There are 73 true regressions.

Almost all of them are due to crates depending on num 0.1, which is ancient. v0.2 has been released more than 6 years ago, so likely all that code is basically unmaintained. This covers 61 of the true regressions. Everything else falls into two categories:

• It didn't have any updates in at least 6 years (10 crates)
• Or I filed an issue:
  • Depends on deprecated and to-be-removed rustc-serialize feature TrashPandacoot/domo-pitchfork#10 (but the last change in this repo was 5 years ago so we'll see if anything happens)
  • Depends on deprecated and to-be-removed rustc-serialize feature cloudflare/lol-html#251 (this repo seems actively maintained, might make sense to wait for them before landing the change -- the problem occurs in a dev-dependency so their users are not affected)

So, it seems like the impact on maintained code is negligible. Nominating for t-libs-api discussion.

[traviscross]

See also the Rust 2024 soft destabilization in:

• Soft-destabilize RustcEncodable & RustcDecodable, remove from prelude in next edition #116016
• Tracking Issue for the 2024 prelude #121042

[Amanieu]

We discussed this in the libs-api meeting. Considering that this has been soft-deprecated for 6 months already, we believe the impact of breakage is low. However:

• Instead of de-stabilizing it, could we just remove this entirely? The soft deprecation message specifically says that this feature will be removed in the future.
• Could we publish a patch release for num 0.1 that removes the use of rustc_encodable_decodable? cc @cuviper

[RalfJung]

@Amanieu do you plan to do a libs-api FCP here, or can I consider this to be team consensus already?

[cuviper]

I can update num v0.1 (and corresponding num-{bigint,complex,rational}) -- since this is a breaking change, I'll probably make it autocfg-detect the unavailability rather than removing it outright, so that "blame" is upstream. 🙂

[Amanieu]

FCP to propose removing RustcEncodable and RustcDecodable entirely.

@rfcbot merge

[rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔