Tracking issues for unstable language features used by `std`

[m-ou-se]

std uses a lot of unstable language features. While core will most likely always have to use language features because it defines things that are part of the core of the language, we can strive for std to eventually be free of unstable language features.

Some of these we'll need to stabilize, but some others we might be able to simply remove with some small changes to the code.

(See also https://github.com/rust-lang/rust/issues/94971 for the library features used by std.)

These are the language features we currently use in std: (This does not include core or alloc.)

• Macro related:
  • [ ] allow_internal_unsafe
  • [ ] allow_internal_unstable
  • [ ] concat_idents
  • [ ] decl_macro
  • [ ] rustc_attrs: rustc_macro_transparency
• Const eval:
  • [ ] const_mut_refs
  • [ ] const_trait_impl
• Panic related:
  • [ ] rustc_attrs: rustc_builtin_macro(std_panic)
  • [ ] lang_items: begin_panic
  • [ ] rustc_attrs: rustc_do_not_const_check
  • [ ] needs_panic_runtime
• Global allocator: (RFC 2492 might be of help here)
  • [ ] alloc_error_handler
  • [ ] allocator_internals
• Diagnostics:
  • [ ] deprecated_suggestion
  • [ ] must_not_suspend
  • [ ] rustc_attrs: rustc_conversion_suggestion
  • [ ] rustc_attrs: rustc_diagnostic_item
  • [ ] rustc_attrs: rustc_insignificant_dtor
  • [ ] rustc_attrs: rustc_lint_query_instability
• Rustdoc:
  • [ ] doc_cfg
  • [ ] doc_cfg_hide
  • [ ] rustdoc_internals
  • [ ] doc_masked
  • [ ] doc_notable_trait
  • [ ] intra_doc_pointers
• Other language features:
  • [ ] lang_items: start
  • [ ] lang_items: termination
  • [ ] lang_items: f32_runtime, f64_runtime
    • Fixed if we move all f32 and f64 methods to core. Libm -> compiler_builtins?
  • [x] associated_type_bounds: https://github.com/rust-lang/rust/pull/95587
  • [x] box_syntax
  • [ ] try_blocks
  • [x] c_unwind: https://github.com/rust-lang/rust/pull/116088
  • [ ] dropck_eyepatch
  • [ ] exhaustive_patterns
  • [ ] linkage
  • [ ] min_specialization
  • [ ] negative_impls
    • We can remove this if we switch to just using PhantomData everywhere.
  • [ ] never_type
  • [x] nll
  • [x] platform_intrinsics: https://github.com/rust-lang/rust/pull/121516
  • [ ] prelude_import
  • [ ] staged_api
  • [ ] thread_local
  • [ ] cfg_target_thread_local
  • [ ] rustc_attrs: rustc_std_internal_symbol
  • [ ] rustc_attrs: rustc_specialization_trait
  • [ ] rustc_attrs: rustc_layout_scalar_valid_range_start, rustc_layout_scalar_valid_range_end

[m-ou-se]

@rust-lang/lang Can y'all please stabilize this entire list? :D Thaanks!

cc @rust-lang/libs

[DemiMarie]

@rust-lang/lang Can y'all please stabilize this entire list? :D Thaanks!

cc @rust-lang/libs

allow_internal_unstable makes no sense to stabilize, so that one can be scratched off the list already. @m-ou-se rightly corrected me, thanks.

[m-ou-se]

allow_internal_unstable makes no sense to stabilize, so that one can be scratched off the list already.

If we stabilize staged_api (to allow other crates to use #[stable] and #[unstable] for their own API), then we should also stabilize allow_internal_unstable.

[bjorn3]

we can strive for std to eventually be free of unstable language features.

I don't think that is completely realistic. It contains several fallbacks for things that need to be explicitly defined when not using libstd, but call still be defined even when libstd is used. For example the global allocator used when no #[global_allocator] is used. Or the wrapper around the main function. These fallbacks shouldn't stabilize I think as it would allow for multiple crates to define the same fallbacks. In addition the fallback mechanism may need to be changed in the future for various reasons. In addition the way the right panic runtime is selected is black magic that involves panic_abort and panic_unwind being part and not part of the crate graph at the same time. Still removing most such unstable features would be nice.

• platform_intrinsics
  • Used for the parts of portable-simd that do not go in core (yet?)

Used by https://github.com/rust-lang/portable-simd/tree/master/crates/std_float

• nll

Removing probably won't change anything. It would reduce test coverage of full nll mode though as removing it switched libstd to the migration mode that is currently the default.

[khuey]

Being able to use rustc_layout_scalar_valid_range_start/end would let me save a lot of memory space in Pernosco.

[jhpratt]

If staged_api is intended to be stabilized at some point, there should be some way for stdlib to indicate that it is special to the compiler. I know I've used #![feature(staged_api)] as a check to see if the crate being compiled is stdlib.

[chrysn]

Stabilizing the scalar_valid_range attributes would not only help save memory space, but also help in error handling across C FFI boundaries that is both idiomatic and zero-cost, because typical i32 results could be expressed as a Result<NonnegativeU32, SomeNewtypeAround(NegativeU32)> whose conversion should become the identity function after optimization.

[bjorn3]

because typical i32 results could be expressed as a Result<NonnegativeU32, SomeNewtypeAround(NegativeU32)> whose conversion should become the identity function after optimization.

I don't know if rustc optimizes Result<NonnegativeI32, NegativeI32> into an i32 right now. In any case even if it does, this is not guaranteed independent of scalar_valid_range being stable or not. The only niche filling optimization guaranteed right now is for Option like enums where the wrapped type has a zero niche.