Implement `?const` opt-out for trait bounds by ecstatic-morse · Pull Request #68140 · rust-lang/rust

ecstatic-morse · 2020-01-12T01:38:39Z

For now, such bounds are treated exactly the same as unprefixed ones in all contexts. RFC 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

ecstatic-morse · 2020-01-12T01:41:08Z

Unfortunately, the straightforward implementation adds a field to ty::TraitRef, which is widely used during trait solving. This is despite the fact that trait solving doesn't need to know about the constness of trait bounds.

I have a few other strategies in mind if the increase in memory usage is too large.

@bors try @rust-timer queue

rust-timer · 2020-01-12T01:41:10Z

Awaiting bors try build completion

bors · 2020-01-12T01:41:21Z

⌛ Trying commit c37571d with merge c6996b5e4d57612637bfa2935848784f02e77848...

@oli-obk

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

oli-obk · 2020-01-12T03:10:37Z

We need to think about the future checks for ?const. Those won't be implementable on the HIR datastructures since we may be calling generic functions from other crates. All the bounds will need to know about ?const in order for a call to know whether the argument must implement a trait or not. Instead of encoding it in traitref you may be able to encode it as a predicate variant

bors · 2020-01-12T04:29:24Z

☀️ Try build successful - checks-azure
Build commit: 4c4563c (4c4563c022384469eb2c6e32b59ea207b319544f)

rust-timer · 2020-01-12T04:29:26Z

Queued 4c4563c with parent f363745, future comparison URL.

ecstatic-morse · 2020-01-12T04:33:01Z

Instead of encoding it in traitref you may be able to encode it as a predicate variant.

That's a good idea. I would need to make changes in the trait solver to ensure that Predicate::Trait and Predicate::TraitConst are treated equivalently, but this may be the Right Way™ to implement this.

rust-timer · 2020-01-12T06:26:13Z

Finished benchmarking try commit 4c4563c, comparison URL.

oli-obk · 2020-01-12T07:20:42Z

Maybe it suffices to make it a field of Predicate::Trait? It could fit into the padding after the tag and before the value. Then you don't have to worry about the treating the same

oli-obk · 2020-01-12T07:37:21Z

Also doesn't really look like a max rss regression, but a perf regression

ecstatic-morse · 2020-01-14T05:30:48Z

After the most recent push, this is closer to the final version, but still not ready for review. The changes to ItemKind::Impl could be split into their own PR. The ConstnessAnd wrapper makes it easier to audit that constness of trait bounds is correctly propagated into ty::Predicate.

oli-obk · 2020-01-14T08:09:59Z

I thunk it would be best if you'd move the first two commits into their own PR as you'll be rebasing all the time otherwise.

bors · 2020-01-16T10:42:26Z

☔ The latest upstream changes (presumably #68272) made this pull request unmergeable. Please resolve the merge conflicts.

…i-obk Use named fields for `{ast,hir}::ItemKind::Impl` Currently, the widely used `ItemKind::Impl` variant is a tuple with seven fields. I want to add an eighth in rust-lang#68140, which means I have to update most matches on this variant anyways. Giving a name to each field improves readability and makes future changes of this nature much simpler. This change will cause several tools to break. I will fix them once this is merged.

ecstatic-morse · 2020-01-20T21:00:44Z

@oli-obk Okay I think this is ready for an initial review. I updated the PR description with a summary of the changes. The diff is pretty noisy, so you might be better off looking at the commits that mention ty::Predicate and ToPredicate separately.

oli-obk

r=me with the comment added

I added the "no ?const bounds in non-const scopes"-situation to the tracking issue

oli-obk · 2020-01-21T07:58:38Z

 }
- GenericBound::Trait(_, TraitBoundModifier::Maybe) => None,
+ GenericBound::Trait(_, TraitBoundModifier::Maybe)
+ | GenericBound::Trait(_, TraitBoundModifier::MaybeConstMaybe) => {


Leave a comment here stating that these are ignored here because they have already errored in ast validation.

oli-obk · 2020-01-21T08:03:57Z

@bors p=1 bitrotty

ecstatic-morse · 2020-01-21T09:50:47Z

Comments added.

@bors r=oli-obk

bors · 2020-01-21T09:50:49Z

📌 Commit 6bd69a1 has been approved by oli-obk

bors · 2020-01-21T10:06:39Z

⌛ Testing commit 6bd69a1 with merge 4c46ef7...

@oli-obk

…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

bors · 2020-01-21T14:21:39Z

💥 Test timed out

oli-obk · 2020-01-21T16:55:08Z

@bors retry

oli-obk · 2020-01-21T16:57:01Z

(a windows builder froze in https://dev.azure.com/rust-lang/rust/_build/results?buildId=18973&view=logs&j=9c50ef33-0f08-5524-430c-de3652601ceb&t=ebc29b8c-b8ce-5d09-e743-211cd7eea1d8&l=5627)

@oli-obk

…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

@ghost

Rollup of 7 pull requests Successful merges: - #67686 (Simplify NodeHeader by avoiding slices in BTreeMaps with shared roots) - #68140 (Implement `?const` opt-out for trait bounds) - #68313 (Options IP_MULTICAST_TTL and IP_MULTICAST_LOOP are 1 byte on BSD) - #68328 (Actually pass target LLVM args to LLVM) - #68399 (check_match: misc unifications and ICE fixes) - #68415 (tidy: fix most clippy warnings) - #68416 (lowering: cleanup some hofs) Failed merges: r? @ghost

bors · 2020-01-21T22:13:29Z

⌛ Testing commit 6bd69a1 with merge 5e8897b...

Rustup to rust-lang/rust#68140 changelog: none

rust-highfive assigned oli-obk Jan 12, 2020

This comment has been minimized.
Sign in to view

ecstatic-morse changed the title ~~Support ?const opt-out for trait bounds~~Implement ?const opt-out for trait boundsJan 12, 2020

Centril added the F-const_trait_bound_opt_out label Jan 12, 2020

ecstatic-morse force-pushed the const-trait-bound-opt-out branch 3 times, most recently from 213ab4d to 3739e6cCompare January 14, 2020 04:47

ecstatic-morse force-pushed the const-trait-bound-opt-out branch from 3739e6c to 3fd239fCompare January 14, 2020 05:36

ecstatic-morse mentioned this pull request Jan 14, 2020
Use named fields for {ast,hir}::ItemKind::Impl#68204
Merged

bors added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jan 16, 2020

ecstatic-morse added 2 commits January 19, 2020 23:41

Add constness field to ast::ItemKind::Impl
01cbe50

Add constness field to hir::ItemKind::Impl
a790f9b

ecstatic-morse mentioned this pull request Jan 21, 2020
Tracking issue for RFC 2632 ?const trait bound opt-out #67794
Closed
2 tasks

oli-obk approved these changes Jan 21, 2020
View reviewed changes

Add comment explaining MaybeConstMaybe lowering
6bd69a1

ecstatic-morse force-pushed the const-trait-bound-opt-out branch from f1b97af to 6bd69a1Compare January 21, 2020 09:46

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 21, 2020

bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jan 21, 2020

bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 21, 2020

Centril mentioned this pull request Jan 21, 2020
Rollup of 7 pull requests #68423
Merged

bors merged commit 6bd69a1 into rust-lang:masterJan 21, 2020

JohnTitor added a commit to JohnTitor/rust-clippy that referenced this pull request Jan 21, 2020
Rustup torust-lang/rust#68140
7ce9b84

bors added a commit to rust-lang/rust-clippy that referenced this pull request Jan 21, 2020
Auto merge of#5075- JohnTitor:rustup-0122, r=flip1995
3e74853
Rustup to rust-lang/rust#68140 changelog: none

ecstatic-morse added a commit to ecstatic-morse/rust-clippy that referenced this pull request Jan 21, 2020
Fix fallout fromrust-lang/rust#68140
1a4a59c

calebcartwright mentioned this pull request Feb 15, 2020
Support const opt-out syntax on trait bounds rust-lang/rustfmt#4054
Closed

ecstatic-morse deleted the const-trait-bound-opt-out branch October 6, 2020 01:42

fmease mentioned this pull request Feb 17, 2024
Support async trait bounds in macros #121044
Merged

Uh oh!

Uh oh!

Conversation

ecstatic-morse commented Jan 12, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ecstatic-morse commented Jan 12, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-timer commented Jan 12, 2020

Uh oh!

bors commented Jan 12, 2020

Uh oh!

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

oli-obk commented Jan 12, 2020

Uh oh!

bors commented Jan 12, 2020

Uh oh!

rust-timer commented Jan 12, 2020

Uh oh!

ecstatic-morse commented Jan 12, 2020• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rust-timer commented Jan 12, 2020

Uh oh!

oli-obk commented Jan 12, 2020

Uh oh!

oli-obk commented Jan 12, 2020

Uh oh!

ecstatic-morse commented Jan 14, 2020

Uh oh!

oli-obk commented Jan 14, 2020

Uh oh!

bors commented Jan 16, 2020

Uh oh!

ecstatic-morse commented Jan 20, 2020

Uh oh!

oli-obk left a comment

Choose a reason for hiding this comment

Uh oh!

oli-obkJan 21, 2020

Choose a reason for hiding this comment

Uh oh!

oli-obk commented Jan 21, 2020

Uh oh!

ecstatic-morse commented Jan 21, 2020

Uh oh!

bors commented Jan 21, 2020

Uh oh!

bors commented Jan 21, 2020

Uh oh!

bors commented Jan 21, 2020

Uh oh!

oli-obk commented Jan 21, 2020

Uh oh!

oli-obk commented Jan 21, 2020

Uh oh!

bors commented Jan 21, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

ecstatic-morse commented Jan 12, 2020•
edited
Loading

ecstatic-morse commented Jan 12, 2020•
edited
Loading

ecstatic-morse commented Jan 12, 2020•
edited
Loading