Tracking Issue for RFC 3762, "Make trait methods callable in const contexts"

[fee1-dead]

This is a tracking issue for the RFC "3762" (rust-lang/rfcs#3762).
The feature gate for the issue is #![feature(const_trait_impl)].

Note

Questions about the usage of this feature should be directed to the t-compiler/project-const-traits Zulip channel. Use t-lang/effects and the RFC (until it gets accepted) to discuss the language feature and future extensions.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Components

• #[const_trait] attribute
• impl const Trait
• T: ~const Trait
• append_const_msg on rustc_on_unimplemented
• #[derive_const]
• trait Destruct

Steps

• Implement the RFC
• Add const trait Trait and migrate away from #[const_trait]
• add a perf stress test for const trait impls and complex bounds that need solving
• Adjust documentation (see instructions on rustc-dev-guide)
• Style updates for any new syntax (nightly-style-procedure)
  • Style team decision on new formatting
  • Formatting for new syntax has been added to the Style Guide
  • (non-blocking) Formatting has been implemented in rustfmt
• Stabilization PR (see instructions on rustc-dev-guide)
  • Error against putting rustc_const_unstable attribute on const impls as they are now insta-stable.
  • Treat const trait default method bodies and const impl bodies as stable const fn bodies. We need to prevent accidentally stabilizing an implementation that uses unstable lang/lib const fn features.
  • Change Rustdoc to display [const] bounds or what syntax we decided it to be.

Unresolved Questions

• #[derive_const] for custom derives (proc macros) Provide a way for derives to know if they were invoked with #[derive_const] #118304

Implementation history

• See Tracking issue for closed RFC 2632, impl const Trait for Ty and [const] (conditionally const) syntax (const_trait_impl) #67792 for previous tracking issue and its history
• Incomplete list of PRs implementing/refining the feature: https://github.com/rust-lang/rust/pulls?q=is%3Apr+label%3AF-const_trait_impl+is%3Aclosed+

[carlocorradini]

This looks amazing 😍
Keep up the fantastic work 🥳

[clarfonthey]

Should this tracking issue also be used for constifying libstd traits or should that get a separate issue? Since that was the trend before the current RFC, but there's been a lot of lapsing since, and it probably would require opening a lot of new issues to fix it.

I think that at least some traits that are kind of fundamental and require extra compiler support (like Fn*) should be tracked here but mostly just want to clarify.

Edit: also to clarify, since I'm particularly interested in constifying a bunch of traits to make SIMD operations const-usable, I'd be more than happy to spearhead the effort to separate out the const traits into their own tracking issues. Just want to make sure this is the desired approach before I do anything.