Don't newly-stabilize already-deprecated ATOMIC_I64_INIT & friends in 1.34

[scottmcm]

@macpp pointed out in #32976 (comment) that 1.34 is about to stabilize some consts that are already deprecated: https://doc.rust-lang.org/nightly/std/sync/atomic/constant.ATOMIC_I64_INIT.html (Note that it's both "stable since 1.34" and "deprecated since 1.34".)

That seems like something that should probably be addressed in the next 3 weeks.

[scottmcm]

cc @alexcrichton because of #57425

Any thoughts on what change, if any, would be right here?

[SimonSapin]

These constants have been deprecated for about a month since #57425. I think we should unstabilize them, and remove them after some deprecation period. I don’t have a strong opinion on whether this month so far is a long enough period. In that case we can simply remove them now.

[alexcrichton]

It looks like these are only stable on nightly so I think it's fine to just remove the constants at any time before they hit stable.

[saleemjaffer]

@scottmcm I would like to take a shot at this. I'm a newbie to rust.

[SimonSapin]

@saleemjaffer Go ahead!  See https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#pull-requests for the PR workflow.

In this case, the issue is about partly reverting the changes in https://github.com/rust-lang/rust/pull/57425/files. The relevant code is in libcore/sync/atomic.rs in the macro that generates constants whose name are given through the $atomic_init macro parameter. The stability attribute of those const items should be reverted to unstable(feature = "integer_atomics", issue = "32976"). This probably involves adding a new $stable_init_const:meta parameter to the macro, among the existing $stable_* parameters.

Note however that only those constants that are stable since 1.34.0 can be reverted to unstable, since that version has not shipped yet.