Tracking issue for RFC 2632, impl const Trait for Ty and ~const (tilde const) syntax
#67792
Open
5 of 11 tasks
Labels
A-const-eval
Area: constant evaluation (mir interpretation)
A-const-fn
Area: const fn foo(..) {..}. Pure functions which can be applied at compile time.
A-traits
Area: Trait system
C-tracking-issue
Category: A tracking issue for an RFC or an unstable feature.
F-const_trait_impl
`#![feature(const_trait_impl)]`
S-tracking-perma-unstable
Status: The feature will stay unstable indefinitely.
T-lang
Relevant to the language team, which will review and decide on the PR/issue.
Comments
ecstatic-morse
changed the title
impl const Trait for Ty syntaximpl const Trait for Ty
2 tasks
ecstatic-morse
added
A-const-fn
Centril
added
the
T-lang
jonas-schievink
added
B-RFC-approved
ecstatic-morse
changed the title
impl const Trait for Tyimpl const Trait for Ty
Centril
added a commit
to Centril/rust
that referenced
this issue
Jan 7, 2020
Parse the syntax described in RFC 2632 This adds support for both `impl const Trait for Ty` and `?const Trait` bound syntax from rust-lang/rfcs#2632 to the parser. For now, both modifiers end up in a newly-added `constness` field on `ast::TraitRef`, although this may change once the implementation is fleshed out. I was planning on using `delay_span_bug` when this syntax is encountered during lowering, but I can't write `should-ice` UI tests. I emit a normal error instead, which causes duplicates when the feature gate is not enabled (see the `.stderr` files for the feature gate tests). Not sure what the desired approach is; Maybe just do nothing when the syntax is encountered with the feature gate is enabled? @oli-obk I went with `const_trait_impl` and `const_trait_bound_opt_out` for the names of these features. Are these to your liking? cc rust-lang#67792 rust-lang#67794 r? @Centril
Centril
added a commit
to Centril/rust
that referenced
this issue
Jan 10, 2020
Parse the syntax described in RFC 2632 This adds support for both `impl const Trait for Ty` and `?const Trait` bound syntax from rust-lang/rfcs#2632 to the parser. For now, both modifiers end up in a newly-added `constness` field on `ast::TraitRef`, although this may change once the implementation is fleshed out. I was planning on using `delay_span_bug` when this syntax is encountered during lowering, but I can't write `should-ice` UI tests. I emit a normal error instead, which causes duplicates when the feature gate is not enabled (see the `.stderr` files for the feature gate tests). Not sure what the desired approach is; Maybe just do nothing when the syntax is encountered with the feature gate is enabled? @oli-obk I went with `const_trait_impl` and `const_trait_bound_opt_out` for the names of these features. Are these to your liking? cc rust-lang#67792 rust-lang#67794 r? @Centril
Centril
added a commit
to Centril/rust
that referenced
this issue
Jan 10, 2020
Parse the syntax described in RFC 2632 This adds support for both `impl const Trait for Ty` and `?const Trait` bound syntax from rust-lang/rfcs#2632 to the parser. For now, both modifiers end up in a newly-added `constness` field on `ast::TraitRef`, although this may change once the implementation is fleshed out. I was planning on using `delay_span_bug` when this syntax is encountered during lowering, but I can't write `should-ice` UI tests. I emit a normal error instead, which causes duplicates when the feature gate is not enabled (see the `.stderr` files for the feature gate tests). Not sure what the desired approach is; Maybe just do nothing when the syntax is encountered with the feature gate is enabled? @oli-obk I went with `const_trait_impl` and `const_trait_bound_opt_out` for the names of these features. Are these to your liking? cc rust-lang#67792 rust-lang#67794 r? @Centril
bors
added a commit
that referenced
this issue
Feb 20, 2020
Allow trait methods to be called on concrete types in a const context This partially implements [RFC 2632](rust-lang/rfcs#2632) by const-checking methods inside an `impl const` block and allowing those methods to be called on concrete types. Calling trait methods on type parameters in a const context is not yet allowed. Implementing this will require much more work. Since we are only concerned with methods on concrete types, we are able to take advantage of the machinery in `Instance::resolve`, which is doing most of the work. This also propagates `#[rustc_const_unstable]` from parent items to child items, making that attribute behave like `#[stable]` and `#[unstable]` do. This allows trait methods to be marked as unstably const. cc #67792 #57563 cc @rust-lang/wg-const-eval r? @oli-obk
jonas-schievink
added
the
A-const-eval
This was referenced Jul 24, 2020
5 tasks
github-actions bot
pushed a commit
to rust-lang/glacier
that referenced
this issue
Nov 20, 2020
=== stdout === === stderr === warning: the feature `const_trait_impl` is incomplete and may not be safe to use and/or cause compiler crashes --> /home/runner/work/glacier/glacier/ices/69487.rs:1:12 | 1 | #![feature(const_trait_impl)] | ^^^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default = note: see issue #67792 <rust-lang/rust#67792> for more information error: A function with the "rust-call" ABI must take a single non-self argument that is a tuple --> /home/runner/work/glacier/glacier/ices/69487.rs:10:5 | 10 | extern "rust-call" fn call_once(self, arg: &usize) -> Self::Output { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error; 1 warning emitted ==============
4 tasks
This was referenced Jun 19, 2023
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
NOTE: See #110395, which tracks a planned rewrite of this feature's implementation
This is the primary tracking issue for rust-lang/rfcs#2632.
The current RFC text can be found at https://internals.rust-lang.org/t/pre-rfc-revamped-const-trait-impl-aka-rfc-2632/15192
This RFC has not yet been accepted. It is being implemented on a provisional basis to evaluate the potential fallout.
cc #57563
The feature gate is
const_trait_impl.Components
#[const_trait]attributeimpl const TraitT: ~const Traitappend_const_msgonrustc_on_unimplemented#[derive_const]trait DestructOpen issues
const fnwith aTraitbound even if the concrete type does not implementconst Trait, but justTrait. This will fail later during evaluation. Some related discussion can be found in Allow using generic trait methods inconst fn#79287 (comment)const implwithout defining one without the feature gate enabled. This should be added before anyimpl constis added to the standard library.#[rustc_const_stable]and#[rustc_const_unstable]so we can properly stabilize (or not) the constness of impls in the standard libraryimpl constwrongly accepts impl with non-const provided methods #79450 shows that with default function bodies in the trait declaration, we can cause non-const functions to exist inimpl const Traitimpls by leaving out these default functions~const. (In the interim, we may want to switch this to use ak#provisional_keywordor similar.)#[default_method_body_is_const], determine the syntax for it instead of existing as an attribute#[derive_const]for custom derives (proc macros) Provide a way for derives to know if they were invoked with#[derive_const]#118304When stabilizing: compiler changes are required:
rustc_const_unstableattribute onconstimpls as they are now insta-stable.default_method_body_is_constbodies andconstimplbodies asstableconst fnbodies. We need to prevent accidentally stabilizing an implementation that uses unstable lang/libconst fnfeatures.~constbounds or what syntax we decided it to be.The text was updated successfully, but these errors were encountered: