rust-lang/rust

Tracking issue for 1.0.0 tracking issues

SimonSapin opened this issue · 14 comments

SimonSapin commented

In the months before Rust 1.0, the stability mechanism was introduced. At first all of the standard library was marked as unstable, then features were stabilized one by one.

I was curious what remains from that time that is still unstable today. I got some data by running:

grep 'active.*1\.0\.0", Some' src/libsyntax/feature_gate.rs

To get them out of the way, I expect these feature gates to be made obsolete (deprecated and eventually removed) by procedural macros 2.0 (#38356):

These have also been proposed for deprecation:

These are "permanently unstable":

Which leaves feature flags dating from 1.0.0, that are still unstable today as of 2017-02-19, and that have some likelihood of being stabilized in the future:

(Individual features should be discussed in their respective tracking issues.)

Edit: I realized that feature_gate.rs does not include library features, so I got more data:

./x.py test src/tools/tidy | grep unstable | grep None | cut -d' ' -f2 | sort > /tmp/now

And in a checkout of the 1.0.0 git tag:

rg '#\[unstable' | grep -o 'feature *= *"[^"]*"' | cut -d\" -f2 | sort -u > /tmp/1.0.0

Got the intersection (com -12 /tmp/now /tmp/1.0.0), and looked manually to remove deprecated features and implementation details, and add tracking issue numbers. This leaves these feature flags:

  • alloc #27783
  • collections #27783 (reexported stable in std, but could still be useful with #![no_std]) Merged into alloc.
  • unicode #27783 (mostly reexported stable in std)
  • io #27802
  • lookup_host #27705
  • set_stdio (No tracking issue! Despite being useful for example to external test harnesses) (gone)
  • step_by #27741
  • step_trait #27741 #42168
  • nonzero #27730
est31 commented

@SimonSapin btw, you could also have run tidy. It outputs you a list of features and whether they are active or stable.

SimonSapin commented

Interesting, thanks. It looks like the it’s same list, but it doesn’t include tracking issue numbers.

nagisa commented

link_llvm_intrinsics is perma-unstable, and so is fundamental IIRC.

SimonSapin commented

@nagisa Ok, edited.

Also edited to add library features. New total count: 29. (Edit: 28. zero_one is deprecated.)

steveklabnik commented

It'd be great to add this to each of their pages in the unstable book. I have some ideas...

SimonSapin commented

@steveklabnik “this” being which of all unstable features are old date back from before 1.0?

steveklabnik commented

I'd like some kind of status like this for all of the flags, honestly. It's just these ones that you've done the work for :)

SimonSapin commented

Ah, so you mean tagging which features we are planning to deprecate vs which ones have some chance of eventual stabilization.

  • 👍3
ishitatsuyuki commented

Triage: is this obsolete?

mark-i-m commented

That would be ironic

SimonSapin commented

@ishitatsuyuki Depends what you mean. This issue is not yet at the point where it should be closed because every feature that existed 1.0.0 are now either stable or removed. I’ve just gone through checkboxes and made a couple updates, but there are still some that are unchecked.

As to whether it’s useful, that’s a different question. When the stability mechanism was introduced some months before 1.0.0 we started out with everything in the standard library and a lot of language features being unstable "by default", then worked on stabilizing (or removing) them one by one. I think it’s mildly interesting to track the progress of that, and in particular to see what’s left and consider why each of those is still blocked.

workingjubilee commented

This issue mentions #[set_stdio] as being of uncertain stabilization future. I got curious and went looking.

In #26868 (comment) it was recommended #[set_stdio] not be made stable. Ever.
In #59775 (comment) #[set_stdio] being unstable was mentioned as a possible blocker to moving libtest out of tree.
#[set_stdio] being unstable may also be a possible blocker for custom test harnesses in general, as noted here. In #31343 some of its associated functions were discussed as being... hm. "A bodge" seems appropriate.

SimonSapin commented

It looks (based on a quick CTRL-F) like https://rust-lang.github.io/rfcs/2318-custom-test-frameworks.html does not discuss capturing stdout/stderr in tests.

I think it’s potentially interesting to discuss the needs for custom test frameworks and potential solutions, but perhaps not in this thread.

  • 👍1
pnkfelix commented

visited for T-compiler backlog bonanza.

Since all of the issues listed here are themselves tracking issues, and now both compiler and lang team are doing regular backlog bonanzas to work through backlog of features, we do not think this kind of meta-tracking issue is buying as much as it did back in 2017-2019.

(We do think it was quite an awesome feat to gather all this info back then though!)

closing

  • 👍2