Skip to content
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

Implement ?const opt-out for trait bounds #68140

Merged
merged 12 commits into from
Jan 21, 2020

Conversation

ecstatic-morse
Copy link
Contributor

@ecstatic-morse ecstatic-morse commented Jan 12, 2020

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
Copy link
Contributor Author

ecstatic-morse commented Jan 12, 2020

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
Copy link
Collaborator

Awaiting bors try build completion

@bors
Copy link
Contributor

bors commented Jan 12, 2020

⌛ Trying commit c37571d with merge c6996b5e4d57612637bfa2935848784f02e77848...

@rust-timer

This comment has been minimized.

@bors

This comment has been minimized.

bors added a commit that referenced this pull request 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
@rust-highfive

This comment has been minimized.

@ecstatic-morse ecstatic-morse changed the title Support ?const opt-out for trait bounds Implement ?const opt-out for trait bounds Jan 12, 2020
@oli-obk
Copy link
Contributor

oli-obk commented Jan 12, 2020

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
Copy link
Contributor

bors commented Jan 12, 2020

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

@rust-timer
Copy link
Collaborator

Queued 4c4563c with parent f363745, future comparison URL.

@ecstatic-morse
Copy link
Contributor Author

ecstatic-morse commented Jan 12, 2020

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
Copy link
Collaborator

Finished benchmarking try commit 4c4563c, comparison URL.

@oli-obk
Copy link
Contributor

oli-obk commented Jan 12, 2020

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
Copy link
Contributor

oli-obk commented Jan 12, 2020

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

@ecstatic-morse ecstatic-morse force-pushed the const-trait-bound-opt-out branch 3 times, most recently from 213ab4d to 3739e6c Compare January 14, 2020 04:47
@ecstatic-morse
Copy link
Contributor Author

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
Copy link
Contributor

oli-obk commented Jan 14, 2020

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
Copy link
Contributor

bors commented Jan 16, 2020

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

@bors 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
tmandry added a commit to tmandry/rust that referenced this pull request Jan 18, 2020
…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
Copy link
Contributor Author

@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.

Copy link
Contributor

@oli-obk oli-obk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

r=me with the comment added

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

@@ -1254,7 +1254,10 @@ impl<'a, 'hir> LoweringContext<'a, 'hir> {
| GenericBound::Trait(ref ty, TraitBoundModifier::MaybeConst) => {
Some(this.lower_poly_trait_ref(ty, itctx.reborrow()))
}
GenericBound::Trait(_, TraitBoundModifier::Maybe) => None,
GenericBound::Trait(_, TraitBoundModifier::Maybe)
| GenericBound::Trait(_, TraitBoundModifier::MaybeConstMaybe) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@oli-obk
Copy link
Contributor

oli-obk commented Jan 21, 2020

@bors p=1 bitrotty

@ecstatic-morse
Copy link
Contributor Author

Comments added.

@bors r=oli-obk

@bors
Copy link
Contributor

bors commented Jan 21, 2020

📌 Commit 6bd69a1 has been approved by oli-obk

@bors 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
Copy link
Contributor

bors commented Jan 21, 2020

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

bors added a commit that referenced this pull request 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
@bors
Copy link
Contributor

bors commented Jan 21, 2020

💥 Test timed out

@bors 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
@oli-obk
Copy link
Contributor

oli-obk commented Jan 21, 2020

@bors retry

@bors 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 added a commit to Centril/rust that referenced this pull request 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
bors added a commit that referenced this pull request Jan 21, 2020
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
Copy link
Contributor

bors commented Jan 21, 2020

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

@bors bors merged commit 6bd69a1 into rust-lang:master Jan 21, 2020
JohnTitor added a commit to JohnTitor/rust-clippy that referenced this pull request Jan 21, 2020
bors added a commit to rust-lang/rust-clippy that referenced this pull request Jan 21, 2020
ecstatic-morse added a commit to ecstatic-morse/rust-clippy that referenced this pull request Jan 21, 2020
@ecstatic-morse ecstatic-morse deleted the const-trait-bound-opt-out branch October 6, 2020 01:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants