Skip to content

Tracking issue for RFC 2632 ?const trait bound opt-out #67794

New issue

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

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

Already on GitHub? # to your account

Closed
1 of 2 tasks
ecstatic-morse opened this issue Jan 2, 2020 · 7 comments
Closed
1 of 2 tasks

Tracking issue for RFC 2632 ?const trait bound opt-out #67794

ecstatic-morse opened this issue Jan 2, 2020 · 7 comments
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@ecstatic-morse
Copy link
Contributor

ecstatic-morse commented Jan 2, 2020

This is the tracking issue for the ?const opt-out for trait bounds described in rust-lang/rfcs#2632. The primary tracking issue for that RFC is #67792. The feature gate for it is const_trait_bound_opt_out.

This RFC has not yet been accepted. It is being implemented on a provisional basis to evaluate the potential fallout.

cc #57563

Implementation steps:

@ecstatic-morse 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 Centril added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Jan 2, 2020
@ecstatic-morse ecstatic-morse changed the title Tracking issue for RFC 2362, ?const trait bound opt-out Tracking issue for RFC 2632 ?const trait bound opt-out Jan 3, 2020
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 Jan 12, 2020
Support `?const` opt-out for trait bounds

For now, such bounds are treated exactly the same as unprefixed ones in all contexts. [RFC 2632](rust-lang/rfcs#2632) does not specify whether such bounds are forbidden outside of `const` contexts, so they are allowed at the moment.

cc #67794

r? @oli-obk
bors added a commit that referenced this issue Jan 21, 2020
…i-obk

Implement `?const` opt-out for trait bounds

For now, such bounds are treated exactly the same as unprefixed ones in all contexts. [RFC 2632](rust-lang/rfcs#2632) does not specify whether such bounds are forbidden outside of `const` contexts, so they are allowed at the moment.

Prior to this PR, the constness of a trait bound/impl was stored in `TraitRef`. Now, the constness of an `impl` is stored in `ast::ItemKind::Impl` and the constness of a bound in `ast::TraitBoundModifer`. Additionally, constness of trait bounds is now stored in an additional field of `ty::Predicate::Trait`, and the combination of the constness of the item along with any `TraitBoundModifier` determines the constness of the bound in accordance with the RFC. Encoding the constness of impls at the `ty` level is left for a later PR.

After a discussion in \#wg-grammar on Discord, it was decided that the grammar should not encode the mutual exclusivity of trait bound modifiers. The grammar for trait bound modifiers remains `[?const] [?]`. To encode this, I add a dummy variant to `ast::TraitBoundModifier` that is used when the syntax `?const ?` appears. This variant causes an error in AST validation and disappears during HIR lowering.

cc #67794

r? @oli-obk
Centril added a commit to Centril/rust that referenced this issue Jan 21, 2020
…t-out, r=oli-obk

Implement `?const` opt-out for trait bounds

For now, such bounds are treated exactly the same as unprefixed ones in all contexts. [RFC 2632](rust-lang/rfcs#2632) does not specify whether such bounds are forbidden outside of `const` contexts, so they are allowed at the moment.

Prior to this PR, the constness of a trait bound/impl was stored in `TraitRef`. Now, the constness of an `impl` is stored in `ast::ItemKind::Impl` and the constness of a bound in `ast::TraitBoundModifer`. Additionally, constness of trait bounds is now stored in an additional field of `ty::Predicate::Trait`, and the combination of the constness of the item along with any `TraitBoundModifier` determines the constness of the bound in accordance with the RFC. Encoding the constness of impls at the `ty` level is left for a later PR.

After a discussion in \#wg-grammar on Discord, it was decided that the grammar should not encode the mutual exclusivity of trait bound modifiers. The grammar for trait bound modifiers remains `[?const] [?]`. To encode this, I add a dummy variant to `ast::TraitBoundModifier` that is used when the syntax `?const ?` appears. This variant causes an error in AST validation and disappears during HIR lowering.

cc rust-lang#67794

r? @oli-obk
@jonas-schievink jonas-schievink added the A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) label Mar 28, 2020
@clarfonthey
Copy link
Contributor

From what I understand, this was recently changed to ~const but none of the tilde-const PRs link back to this one, and the issue name/description should be updated?

@clarfonthey
Copy link
Contributor

cc @oli-obk @fee1-dead since from what I understand you two know the most about this change

@fee1-dead
Copy link
Member

The opt-out is no longer needed. The previous scheme was:

const fn a<T: /* inferred const bound */ Foo + /* opt-out normal trait bound */ ?const Bar>

And the current scheme is now:

const fn a<T: /* normal trait bound */ Foo + /* const bound if called in a const context */ ~const Bar>

This issue should be closed, but it can be reopened if somehow we decide to use ?const opt-out again.

@oli-obk oli-obk closed this as completed Sep 1, 2021
@jplatte
Copy link
Contributor

jplatte commented Sep 1, 2021

So where is ~const tracked then? #67792?

@oli-obk
Copy link
Contributor

oli-obk commented Sep 1, 2021

yea, const_trait_impl requires the opt in syntax, otherwise you can't write anything but trivial impls

@clarfonthey
Copy link
Contributor

So... is there no dedicated tracking issue for ~const, then?

Mostly because I don't see any easy place someone can look to know what the new syntax means.

@oli-obk
Copy link
Contributor

oli-obk commented Sep 1, 2021

I updated the const_trait_impl tracking issue to link to the latest RFC text

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

7 participants