Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking issues for unstable language features used by std #94970

Open
5 of 47 tasks
m-ou-se opened this issue Mar 15, 2022 · 8 comments
Open
5 of 47 tasks

Tracking issues for unstable language features used by std #94970

m-ou-se opened this issue Mar 15, 2022 · 8 comments
Labels
metabug Issues about issues themselves ("bugs about bugs") T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Comments

@m-ou-se
Copy link
Member

m-ou-se commented Mar 15, 2022

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
    • 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:
@m-ou-se m-ou-se added T-lang Relevant to the language team, which will review and decide on the PR/issue. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Mar 15, 2022
@m-ou-se
Copy link
Member Author

m-ou-se commented Mar 15, 2022

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

cc @rust-lang/libs

@m-ou-se m-ou-se changed the title Tracking issues for unstable language features in std Tracking issues for unstable language features used by std Mar 15, 2022
@DemiMarie
Copy link
Contributor

DemiMarie commented Mar 16, 2022

@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
Copy link
Member Author

m-ou-se commented Mar 16, 2022

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
Copy link
Member

bjorn3 commented Mar 16, 2022

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
Copy link
Contributor

khuey commented May 16, 2022

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

@jhpratt
Copy link
Member

jhpratt commented Jun 7, 2022

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
Copy link
Contributor

chrysn commented Jul 26, 2022

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
Copy link
Member

bjorn3 commented Jul 26, 2022

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.

@joshtriplett joshtriplett added metabug Issues about issues themselves ("bugs about bugs") and removed C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC labels Aug 10, 2022
bors added a commit to rust-lang-ci/rust that referenced this issue Jan 23, 2023
Do not use box syntax in `std`

See rust-lang#94970 and rust-lang#49733. About half of the `box` instances in `std` do not even need to allocate, the other half can simply be replaced with `Box::new`.

`@rustbot` label +T-libs
r? rust-lang/libs
@workingjubilee workingjubilee added F-rustc_attrs Internal rustc attributes gated on the `#[rustc_attrs]` feature gate. and removed F-rustc_attrs Internal rustc attributes gated on the `#[rustc_attrs]` feature gate. labels Mar 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
metabug Issues about issues themselves ("bugs about bugs") T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

8 participants