… complicated, but will probably never be stabilized.
We currently have them because they are convenient. I don't think they are intended for stabilization and are expected to be subsumed by general deref patterns.
All usage has been removed from the compiler and standard library. #[rustc_box] Box::new()
is the new equivalent.
We should throw it out!
Currently used in rustdoc for standard library types. There's some effort to make a more stable version of it: 94909
Not very nice solution to the parametric dropck being too strict sometimes. There's an RFC now: https://github.com/rust-lang/rfcs/pull/3390
Something from the most recent balancing of coherence that makes some things work that should work, I don't think it's ever intended to be stabilized?
Allows using
#[link_name="llvm.*"]
.
Needed for things like stdarch.
The #[linkage]
attribute. Includes things like weak linking. We should probably stabilize this at some point but there are design concerns.
Perma unstable internal thing for panic=abort/unwind.
Very recent, though I don't think it belongs under internal feature gates?
Again, internal for panic=abort/unwind.
standard library const fn
implementation detail.
Using the compiler is inherently unstable, nothing to stabilize here (although project stable MIR does go into that direction).
Implementation detail of rustdoc
rustdoc lint about missing examples, probably doesn't belong in internal features.
Using a custom entry point for a program.
We'd like to stabilize this, but we need to evaluate the function signature and what commitments we make for which parts of the standard library work.
Comment by Josh Triplett in 2021.
Subsumed by
StructuralPartialEq
, cannot move to removed until a library feature with the same name exists.
We should probably do that?
As an aside: this is about the worst feature name ever
Allows using the "rust-call"
ABI, needed for the fn traits. There is probably quite some design work to do on those if we plan to stabilize them.
T-lang is confused what the status of these is. Needs some organizational cleanup and can probably be pushed towards stabilization afterwards.
From the author:
In upstream Rust, not likely: I have absolutely no interest in upstreaming anything anymore. I'm (relatively) actively developing my Rust fork which supports AMDGPU however
Looks like this can be closed.
There's an in-progress RFC for interrupt calling conventions: https://github.com/rust-lang/rfcs/pull/3246. The last activity there was almost a year ago.
No activity for two years. There's an open issue about rustc checking ABI compliance (there are limits) instead of LLVM. No updates on that issue either.
There are design concerns and many unresolved questions. Last activity was a year ago.
almost ready for stabilization, basically juts needs the ConstParamTy
trait implemented and to figure out sizedness of const args. see also pcg-50
The consensus was to not stabilize #[alloc_error_handler] for now and instead make it panic by default as proposed in #66741.
Ongoing design concerns from July 2021.
Needs an RFC. There as been an awesome summary in 2022, but not much progress.
Waiting for inline_const
.
Support for more arches in inline assembly. Not much progress, but something we clearly want.
Waiting for extern "C-unwind"
.
Fairly recent without too much progress.
The implementation is incomplete.
We might want to add this to the types team agenda.
by Josh Triplett.
T-lang is unsure about the status and there seems to be a lot of work to do.
The status seems unclear.
Recent feature with design left to do around Send
bounds.
About to be stabilized.
Tagging as ready-to-stabilize based on previous lang discussion.
by Josh Triplett in March 2022.
This is marked as incomplete, so there's still lots of work to d- it's stabilized. Why is there still a language feature open???
The feature can be marked as accepted.
No one knows about the status of this. But since -Zsanitize
is still unstable, it's probably at least blocked on that
There don't seem to be any blockers. Last activity in July 2022.
Like cfg_target_abi
but better! Except part of the RFC that added this was withdrawn! I have no idea! This badly needs a summary.
Added in Feburary 2022, no updates.
Added for Atomic*::from_mut
. No updates since Februrary 2022.
For #[thread_local]
. Seems weird to have a dedicated feature for the cfg part.
There is a lot of discussion. Last comment:
It looks like cfg(accessible(…)) may be at a state where we could stabilize enough of it to be generally useful, and what's available is enough that I'd consider it to unblock this. #64797
by Josh Triplett in June 2022.
Less than a year old, there still seems to be some work to do.
Basically needs the stmt_expr_attributes
feature to work.
We discussed this in today's @rust-lang/lang meeting. We felt like an extern "ABI" does make sense for most of the functionality of this. What's left sounds like the generation of a special symbol, and it's not clear if we should have that as a built-in attribute, a library attribute, or something in a crate.
by Josh Triplett in July 2022
No acticity since August 2022. Maybe wg-debugging knows more, since they started that feature.
A major blocker is being removed in #104826.
Very recent.
There has been recent discussion on this in #93481.
"Rust"
and "C"
are stable - no blockers for the rest.
This should be stabilized
This feature… has had quite a journey so far and will continue on that journey. The cool RFC https://github.com/rust-lang/rfcs/pull/3352 will be very relevant here, the author of that RFC should get more active there instead of doing backlog bonanzas >:(
Blocked on const_trait_impl
People are currently working on fixing the last blocker.
There are still concerns around drop elaboration and optimizations, FCP was cancelled.
Same as const_mut_refs
.
The tracking issue was locked because of too many off-topic comments, work is slowly but steadily progressing.
Probably needs const_trait_impl
.
There are open questions around the scope of the macro. Not much recent activity but tons of backreferences from random projects (thank you GitHub).
The tracking issue was closed in April 2022 due to lack of activity on the experiment. Someone expressed interested in drafting a T-lang MCP but no activity since then.
Needs an implementation, someone claimed it in February 2023.
…yeah, that feature. Not much relevant activity since forever, but everyone would love to get it. It needs some serious design work.
this issue has been stalled on disagreements about how to handle a nasty problem found during implementation. https://internals.rust-lang.org/t/interaction-of-user-defined-and-integral-fallbacks-with-inference/2496
Mostly for env::set_var
, which is unsound in some circumstances. The author of the tracking issue deleted their Github account. There's some work to do for designing all of this.
Already part of rustc_deprecated
, added in March 2022 with no activity since then.
Seems ready for stabilization
There has been lots of work happening in that space with the diagnostics
namespace, this will probably become part of that work.
There's still discussion on whether it should be on by default, but the last activity on that was in late 2022. An RFC has started to be written.
See doc_auto_cfg
.
See doc_auto_cfg
.
The tracking issue doesn't follow the tracking issue label and I don't even know what this feature does.
Looking a bit more, it seems like it exists to avoid showing impls linked via extern crate
in docs? And it was mostly implemented for std
.
Recent feature, part of the effort towards dyn async fn in trait.
There has been some recent confusion on what's needed for stabilization. It seems like all the questions about syntax have been resolved, except for some people wanting to bikeshed Rusts range syntax again.
This deserves a closer lang look
I do feel we need the never patterns feature – or some equivalent thing. This is probably just blocked on never being stabilized.
by Niko Matsakis in May 2021
No activity since when it was opened in August 2022.
The conclusion from a previous lang team meeting was that the correct answers to a bunch of the hard questions here is tied to custom DSTs and we should attempt to find the minimum possible thing to stabilise. However the alignment issues makes deciding what that minimum thing is difficult. Especially as custom DSTs may never land.
From a great summary in August 2022
Is this fully implemented and ready for potential stabilization, or is there any blocker?
by Josh Triplett in June 2022. No response.
Same as ffi_const
.
Looks like this is actually a horrible bad not good hack and the tracking issue and RFC was closed in June 2022. The ffi-unwind project is looking at this.
The feature can be removed
No real activity since August 2021. It should be extended to also support methods, no blockers otherwise.
There's an unsoundness together with box_syntax: https://github.com/rust-lang/rust/issues/105084. Otherwise, no activity on the tracking issue since when it was opened in March 2022. Probably blocked on generators anyways. The possible interactions with async blocks are not mentioned.
Some activity 2022, without many updates. It still needs lots of design work.
No progress in 2022, but seems to be ready.
note: not actually ready, the impl is error prone and we need refactorings in the compiler to be more sure that the current impl is maintainable - boxy
No activity since GAT stabilization, but T-types is probably tracking this.
not fully implemented and the things that are implemented are broken in hard/impossible to fix ways. likely to be removed and replaced by a not-yet implemented min_generic_const_exprs
(see also pcg-50)
The main part was stabilized, only the in_slices part remains unstable. The status is unclear.
The implementation was pretty broken recently. It seems to have been mostly fixed and tests were added, but some semantics are still unclear.
Was added in July 2022, no activity since then. There are unresolved questions.
Was added in October 2022, no activity since then. Also no unresolved questions listed.
Implemented in 2021 (that took a while :D), no concerns known. Seems to be ready to stabilize!
Stabilize it
A four-digit issue number, wooow. After only 10 years (basically nothing), work on implementing it has finally started and is currently happening (as we speak).
On its way towards stabilization, but there are concerns around post-mono errors.
Blocked on inline_const
.
rustdoc, no activity since May 2021.
There are some remaining design questions and work to do.
Almost stabilized, then ripped out of beta because they were broken. They should be fixed now, but more testing is needed.
That linked issue is wrong. It's https://github.com/rust-lang/rust/issues/72059 now which mentions that this should be perma-unstable.
Fix the issue number
Lang team design meeting proposed: https://github.com/rust-lang/lang-team/issues/191
Part of it ($$
) was about to be stabilized but then reverted due to $$crate
. There seems to be plenty of discussion, altough it seems that ${ignore()}
is almost uncontroversial and may be stabilized soon.
@SamPruden I'd also like to see this stabilize. It looks like there's at least one open issue that probably blocks it, though: F-marker_trait_attr
By scottmcm in May 2022. Requires a little more attention but seems to be close now?
499 hidden items
No comment on specialization, other than GitHub issues being really bad to navigate the precise state of the feature.
This seems like it may be ready to stabilize. Could we get a stabilization report and documentation PR?
by Josh Triplett in July 2022. Spoiler: we could not. Needs a stabilization report.
No comments since 2021, but tmandry did add it to a wg-async work project, so there seems to be some attention now.
The linked issue was closed, we now have a different one, 90957, which was FCP-merged in July 2022 but then there was some more discussion and things and it seems to be stuck now since then.
Update the issue
The linked tracking issue was closed in favor of 99424 for this.
AFAIK, it's still not implemented on some tier 1 platforms (Apple targets).
by petrochenkov in Nov 2022.
Another one of those old major complicated features, plenty of those out there.
The tragedy. We basically must implement type inference fallback to be !
instead of ()
but can't because that makes code sad.
See never_type
The one benefit is that cfg-if
could use it and become a normal cargo dep of core
. But there isn't much benefit otherwise.
We talked about this in today's @rust-lang/lang meeting.
We do think it makes sense to make this coverage(off) and leave room for other coverage arguments in the future.
Apart from that, if someone wants to write a stabilization report, we'd be happy to stabilize this.
by Josh Triplett in July 2022
Part of sanitizers. Not much to say about this specifically.
The status of it seems unclear, there's been some name bikeshedding in 2022.
Very recent.
No activity since 2019 except
Paging @nikomatsakis, it would help to have a summary of this to know what state it's in and whether it's on a path to stabilization.
by Josh Triplett in February 2022.
There are some unresolved questions about propagation of the attribute and similar attributes in June 2022.
Part of core SIMD. I have no idea whether this is ever intended to be stabilized or just an implementation detail.
The plugin infrastructure is kinda deprecated, but servo and rmc still use it.
Not much activity since 2021, seems to need an RFC and better motivation.
Needs a summary on the tracking issue and possibly splitting it, but the def_site hygiene requires more detailed hygiene work (which decl_macro also needs).
Stabilized on all platforms but x86 (32) now.
Implementation detail of addr_of{_mut}
for now. There are some small unresolved questions, but can probably pushed towards stabilization with some work.
Needs an RFC as there are plenty of questions.
Enums with #[repr(u128)]
.
There were problems with LLVM debuginfo. These are now fixed for fieldless enums, but not for enums with fields.
As with all SIMD things, the linked tracking issues aren't helpful :/.
Fairly new. There were a few issues with default bodies that seem to be fixed now.
This was added in May 2022. Apparently there's a bug in it that was found recently.
I can't comment on SIMD issues.
Clean up SIMD tracking issues and features
min_specialization
but worse.
Everyone is saying that it would be cool but noe response to Niko's request for a summary all the way back in November 2021.
Needs a summary
There was an attempt to stabilize the "memory model uncontroversial" part but it was rejected and is mostly waiting on the memory model now (or at least at the subset of the memory model that says how int2ptr casts work).
There are still many design concerns around deref patterns, this feature implements a small subset for String
only.
Stabilization PR FCP was completed and the RFC has just been approved while I was writing this.
There may be soundness issues with this feature.
Should be in the backlog for T-types now.
Was turned into an RFC and approved in December 2022, so there seems to be work going on.
There are design concerns about how it interacts with the initness requirements for unions.
I'm trying to figure out the current state of this feature. What's the current status of trivial_bounds? Are there still blocking issues that would prevent this from being stabilized? Or does this just need a stabilization report and FCP?
The last update I found about blocking concerns, across the several issues about this, seems to be from 2019 talking about limitations in chalk.
by Josh Triplett in February 2023
There is still some design work to do around ?
. The most recent update was the experimental addition of do yeet
.
Was getting very close to stabilization, now there are a few questions about the possible ways where the hidden type can be defined.
Was de-RFCed. It's about to be removed from the frontend of the compiler, but the rest will stay for now as future better syntax may make it relevant again.
There's a type inference failure regression from it and no clear consensus on how it should be resolved.
Added in June 2022, some unresolved questions remaining.
There are some questions but the status seeems unclear to me.
Needed for <Box<dyn FnOnce> as FnOnce>
for now, but it's not clear whether we ever want to stabilize it.
T-lang noted some concerns in January 2022.
Added in February 2022. There are some unresolved questions.
The status seems unclear, but there's some question about whether we should wait for C to do this.
I did it, yeet! Part of of the ?
effort.