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 Tracking issue for log_syntax, trace_macros #29598
• trace_macros Tracking issue for log_syntax, trace_macros #29598
• macro_reexport Tracking issue for macro_reexport feature #29638
• plugin Tracking issue for plugin stabilization (plugin, plugin_registrar features) #29597 (removed)
• plugin_registrar Tracking issue for plugin stabilization (plugin, plugin_registrar features) #29597 (removed)
• custom_attribute Tracking issue for custom_attribute features #29642
• custom_derive Tracking issue for custom_derive feature #29644
• rustc_attrs Tracking issue for custom_attribute features #29642
• quote Tracking issue for quote feature #29601

These have also been proposed for deprecation:

• main Tracking issue for main feature #29634
• placement_in_syntax Tracking issue for placement new #27779 (feature removed)
• box_syntax Tracking issue for placement new #27779 Tracking issue for box_syntax #49733 (removed)
• box_patterns Tracking issue for box_patterns feature #29641

These are "permanently unstable":

• link_llvm_intrinsics Tracking issue for link_llvm_intrinsics #29602
• fundamental Tracking issue for fundamental feature #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 Tracking issue for the start feature #29633
• link_args Tracking issue for link_args stabilization #29596
• linkage Tracking issue for the linkage feature #29603
• asm Tracking issue for asm (inline assembly) #29722
• simd Tracking issue for SIMD support #27731
• simd_ffi Tracking issue for SIMD support #27731
• allocator Tracking issue for changing the global, default allocator (RFC 1974) #27389
• thread_local Tracking issue for thread_local stabilization #29594
• unboxed_closures Tracking issue for Fn traits (unboxed_closures & fn_traits feature) #29625
• concat_idents Tracking issue for concat_idents #29599
• non_ascii_idents Tracking issue for non-ASCII identifiers (feature "non_ascii_idents") #28979 Tracking issue for RFC 2457, "Allow non-ASCII identifiers" #55467
• optin_builtin_traits Tracking Issue for auto traits (auto_traits) -- formerly called opt-in built-in traits (optin_builtin_traits) #13231
• on_unimplemented Tracking issue for on_unimplemented feature #29628
• associated_consts Tracking issue for associated_consts feature #29646
• slice_patterns Tracking issue for RFC #495 (features slice_patterns and advanced_slice_patterns) #23121
• advanced_slice_patterns Tracking issue for RFC #495 (features slice_patterns and 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:

• alloc Tracking issue for location of facade crates #27783
• collections Tracking issue for location of facade crates #27783 (reexported stable in std, but could still be useful with #![no_std]) Merged into alloc.
• unicode Tracking issue for location of facade crates #27783 (mostly reexported stable in std)
• io Tracking issue for Read::chars #27802
• lookup_host Tracking issue for DNS in std::net #27705
• set_stdio (No tracking issue! Despite being useful for example to external test harnesses) (gone)
• step_by Tracking issue for step_by stabilization #27741
• step_trait Tracking issue for step_by stabilization #27741 Tracking issue for step_trait stabilization #42168
• nonzero Tracking issue for NonZero/Unique/Shared stabilization #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 #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]

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.

[pnkfelix]

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