-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Implement ?const
opt-out for trait bounds
#68140
Conversation
Unfortunately, the straightforward implementation adds a field to I have a few other strategies in mind if the increase in memory usage is too large. @bors try @rust-timer queue |
Awaiting bors try build completion |
⌛ Trying commit c37571d with merge c6996b5e4d57612637bfa2935848784f02e77848... |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
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
This comment has been minimized.
This comment has been minimized.
?const
opt-out for trait bounds?const
opt-out for trait bounds
We need to think about the future checks for |
☀️ Try build successful - checks-azure |
Queued 4c4563c with parent f363745, future comparison URL. |
That's a good idea. I would need to make changes in the trait solver to ensure that |
Finished benchmarking try commit 4c4563c, comparison URL. |
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 |
Also doesn't really look like a max rss regression, but a perf regression |
213ab4d
to
3739e6c
Compare
After the most recent push, this is closer to the final version, but still not ready for review. The changes to |
3739e6c
to
3fd239f
Compare
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. |
☔ 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.
@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 |
There was a problem hiding this 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) => { |
There was a problem hiding this comment.
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.
@bors p=1 bitrotty |
f1b97af
to
6bd69a1
Compare
Comments added. @bors r=oli-obk |
📌 Commit 6bd69a1 has been approved by |
…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
💥 Test timed out |
@bors retry |
…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
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
Rustup to rust-lang/rust#68140 changelog: none
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 animpl
is stored inast::ItemKind::Impl
and the constness of a bound inast::TraitBoundModifer
. Additionally, constness of trait bounds is now stored in an additional field ofty::Predicate::Trait
, and the combination of the constness of the item along with anyTraitBoundModifier
determines the constness of the bound in accordance with the RFC. Encoding the constness of impls at thety
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 toast::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