-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 issue for RFC 2632, impl const Trait for Ty
and ~const
(tilde const) syntax
#67792
Open
5 of 11 tasks
Open
5 of 11 tasks
Labels
A-const-eval
Area: Constant evaluation, covers all const contexts (static, const fn, ...)
A-trait-system
Area: Trait system
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
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
Tracking issue for RFC 2362,
Tracking issue for RFC 2362, Jan 2, 2020
impl const Trait for Ty
syntaximpl const Trait for Ty
2 tasks
ecstatic-morse
added
A-const-fn
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
labels
Jan 2, 2020
Centril
added
the
T-lang
Relevant to the language team, which will review and decide on the PR/issue.
label
Jan 2, 2020
jonas-schievink
added
B-RFC-approved
Blocker: Approved by a merged RFC but not yet implemented.
and removed
B-RFC-approved
Blocker: Approved by a merged RFC but not yet implemented.
labels
Jan 2, 2020
ecstatic-morse
changed the title
Tracking issue for RFC 2362,
Tracking issue for RFC 2632, Jan 3, 2020
impl const Trait for Ty
impl 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
Area: Constant evaluation, covers all const contexts (static, const fn, ...)
label
Mar 28, 2020
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 ==============
This was referenced Jun 19, 2023
85 tasks
This was referenced Oct 29, 2024
4 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
A-const-eval
Area: Constant evaluation, covers all const contexts (static, const fn, ...)
A-trait-system
Area: Trait system
C-tracking-issue
Category: An issue tracking the progress of sth. like the implementation of an RFC
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.
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 Trait
T: ~const Trait
append_const_msg
onrustc_on_unimplemented
#[derive_const]
trait Destruct
Open issues
const fn
with aTrait
bound 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 impl
without defining one without the feature gate enabled. This should be added before anyimpl const
is 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 const
wrongly 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 Trait
impls by leaving out these default functions~const
. (In the interim, we may want to switch this to use ak#provisional_keyword
or 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_unstable
attribute onconst
impl
s as they are now insta-stable.default_method_body_is_const
bodies andconst
impl
bodies asstable
const fn
bodies. We need to prevent accidentally stabilizing an implementation that uses unstable lang/libconst fn
features.~const
bounds or what syntax we decided it to be.The text was updated successfully, but these errors were encountered: