Rust: Tracking issue for 1.0.0 tracking issues

[SimonSapin]

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):

• [ ] log_syntax #29598
• [ ] trace_macros #29598
• [x] macro_reexport #29638
• [ ] plugin #29597
• [ ] plugin_registrar #29597
• [x] custom_attribute #29642
• [x] custom_derive #29644
• [x] rustc_attrs #29642
• [x] quote #29601

These have also been proposed for deprecation:

• [ ] main #29634
• [x] placement_in_syntax #27779 (feature removed)
• [ ] box_syntax #27779 #49733
• [ ] box_patterns #29641

These are "permanently unstable":

• link_llvm_intrinsics #29602
• fundamental #29635

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:

• [ ] start #29633
• [ ] link_args #29596
• [ ] linkage #29603
• [ ] asm #29722
• [ ] simd #27731
• [ ] simd_ffi #27731
• [x] allocator #27389
• [ ] thread_local #29594
• [ ] unboxed_closures #29625
• [ ] concat_idents #29599
• [ ] non_ascii_idents #28979 https://github.com/rust-lang/rust/issues/55467
• [ ] optin_builtin_traits #13231
• [x] on_unimplemented #29628
• [x] associated_consts #29646
• [x] slice_patterns #23121
• [x] advanced_slice_patterns #23121

(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:

• [x] alloc #27783
• [x] collections #27783 (reexported stable in std, but could still be useful with #![no_std]) Merged into alloc.
• [x] unicode #27783 (mostly reexported stable in std)
• [x] io #27802
• [x] lookup_host #27705
• [ ] set_stdio (No tracking issue! Despite being useful for example to external test harnesses)
• [x] step_by #27741
• [ ] step_trait ~#27741~ https://github.com/rust-lang/rust/issues/42168
• [x] nonzero #27730

[est31]

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

[SimonSapin]

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

[nagisa]

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

[SimonSapin]

@nagisa Ok, edited.

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

[steveklabnik]

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

[SimonSapin]

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

[steveklabnik]

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]

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

[ishitatsuyuki]

Triage: is this obsolete?

[mark-i-m]

That would be ironic

[SimonSapin]

@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]

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

In https://github.com/rust-lang/rust/issues/26868#issuecomment-126773333 it was recommended #[set_stdio] not be made stable. Ever.
In https://github.com/rust-lang/rust/issues/59775#issuecomment-525360256 #[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]

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.