Skip to content

Tracking issues for unstable language features used by std #94970

Open
@m-ou-se

Description

@m-ou-se
Member

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 #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 macro_metavar_expr_concat
      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?
    • box_syntax
      try_blocks
      dropck_eyepatch
      exhaustive_patterns
      linkage
      min_specialization
    • negative_impls
      • We can remove this if we switch to just using PhantomData everywhere.
    • never_type
      nll
      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

Activity

added
T-langRelevant to the language team
C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
T-libsRelevant to the library team, which will review and decide on the PR/issue.
on Mar 15, 2022
m-ou-se

m-ou-se commented on Mar 15, 2022

@m-ou-se
MemberAuthor

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

cc @rust-lang/libs

changed the title [-]Tracking issues for unstable language features in `std`[/-] [+]Tracking issues for unstable language features used by `std`[/+] on Mar 15, 2022
DemiMarie

DemiMarie commented on Mar 16, 2022

@DemiMarie
Contributor

@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

m-ou-se commented on Mar 16, 2022

@m-ou-se
MemberAuthor

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

bjorn3 commented on Mar 16, 2022

@bjorn3
Member

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

khuey commented on May 16, 2022

@khuey
Contributor

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

jhpratt

jhpratt commented on Jun 7, 2022

@jhpratt
Member

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

chrysn commented on Jul 26, 2022

@chrysn
Contributor

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

bjorn3 commented on Jul 26, 2022

@bjorn3
Member

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.

9 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    T-langRelevant to the language teamT-libsRelevant to the library team, which will review and decide on the PR/issue.metabugIssues about issues themselves ("bugs about bugs")

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @joshtriplett@khuey@chrysn@m-ou-se@jhpratt

        Issue actions

          Tracking issues for unstable language features used by `std` · Issue #94970 · rust-lang/rust