Tracking GitHub Issue Issues

[nixpulvis]

I’m creating this thread because I feel there is a mismatch in expectations between some people following https://github.com/rust-lang/rust/issues/24111, myself included. I’m not creating this because I’m super upset or angry. I would just like to avoid further noise on the GitHub thread.

It seems like it should be possible to leave an issue “Open” until it’s been marked as accepted or removed in rust/src/libsyntax/feature_gate.rs to avoid the kind of confusion that has happened here. I’m unclear as to why there is a necessary “window where something is closed in nightly and the resolution still hasn’t landed in stable” that effects the status of a tracking issue.

I’ve been following Rust development on and off for a few years now, but I can’t claim to be an expert, or deeply knowledgeable, so please, if there’s previous discussion, or workflows I’m unaware of, link them here.

[steveklabnik]

I’m unclear as to why there is a necessary “window where something is closed in nightly and the resolution still hasn’t landed in stable” that effects the status of a tracking issue.

I don’t know a ton about this specific tracking issue, but this is how Rust development works, thanks to the train model. Things land on master, and then from there move to beta, and then stable. Issues track master as well, since that’s where the work was done. The same thing happens with standard library apis; https://doc.rust-lang.org/stable/std/primitive.isize.html#method.to_ne_bytes says that it’s not stable, but if you click on that issue, it’s closed, because it’s been stabilized in nightly, and has already even hit beta https://doc.rust-lang.org/beta/std/primitive.isize.html#method.to_ne_bytes

[nixpulvis]

OK, that makes sense, but I’m still a little unclear. int_to_from_bytes is part of the STD lib so not tracked in src/libsyntax/feature_gate.rs, which makes sense. Calling int_to_from_bytes from stable Rust today correctly complains about using a nightly only feature.

The case with const_fn is that it’s still “active” in src/libsyntax/feature_gate.rs, which I believe is akin to #[unstable(...)] on an STD item. Is this correct?

Since most of the functionality listed in the original RFC has been implemented, with edge cases now being tracked in their own issues linked to at the top of the tracking issue we’re discussing. Is the solution to mark the const_fn as “accepted”? Or are the remaining issues being rolled under this feature gate still? I’m not very clear on this.

[jethrogb]

I also agree that any features listed as active in master should point to an OPEN tracking issue.