make rustc_encodable_decodable feature properly unstable

[RalfJung]

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

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.