-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Try to evaluate in try unify and postpone resolution of constants that contain inference variables #95179
Conversation
Some changes occured to the CTFE / Miri engine cc @rust-lang/miri |
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.
a few general nits, apart from that r=me
This comment has been minimized.
This comment has been minimized.
eb3a01f
to
7d708fb
Compare
This comment has been minimized.
This comment has been minimized.
7d708fb
to
8ff1edb
Compare
This comment has been minimized.
This comment has been minimized.
Well ok this seems to behave badly with incremental. Only tested ui locally. |
@@ -567,14 +569,27 @@ pub(super) fn thir_abstract_const<'tcx>( | |||
} | |||
} | |||
|
|||
/// Tries to unify two abstract constants using structural equality. | |||
#[instrument(skip(tcx), level = "debug")] | |||
pub(super) fn try_unify<'tcx>( |
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.
why do we need this to be pub(super)
here? additionally, why the try_unify_inner
split, can't we use ContextUnifyCtxt::new(tcx, param_env).try_unify(a, b)
everywhere instead?
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.
I thought this was the better abstraction, since always creating a ConstUnifyCtxt
prior to that call didn't seem ideal at first. But we're calling try_unify
only twice (besides the recursive calls) anyway and only in this file, so I got rid of the inner method.
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.
yeah, might have to guard against the infer vars in the param env as well.
Instead of canonicalization you should probably erase_regions
which 1) improves caching 2) gets rid of region infer variables
also generally: please mark review comments as resolved after they are no longer relevant Github sadly removes the context from review comments after a force push (I think), so I can't easily tell whether specific comments are still relevant. While you're still working on it, its also preferable to only push new commits if possible. |
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.
some last nits 😅 after that r=me
@bors r+ |
📌 Commit 11a70db has been approved by |
⌛ Testing commit 11a70db with merge d3d54c547b90b9e2fbd58a0f4c803d94749d9e38... |
Try to evaluate in try unify and postpone resolution of constants that contain inference variables We want code like that in [`ui/const-generics/generic_const_exprs/eval-try-unify.rs`](https://github.com/rust-lang/rust/compare/master...b-naber:eval-in-try-unify?expand=1#diff-8027038201cf07a6c96abf3cbf0b0f4fdd8a64ce6292435f01c8ed995b87fe9b) to compile. To do that we need to try to evaluate constants in `try_unify_abstract_consts`, this requires us to be more careful about what constants we try to resolve, specifically we cannot try to resolve constants that still contain inference variables. r? `@lcnr`
Try to evaluate in try unify and postpone resolution of constants that contain inference variables We want code like that in [`ui/const-generics/generic_const_exprs/eval-try-unify.rs`](https://github.com/rust-lang/rust/compare/master...b-naber:eval-in-try-unify?expand=1#diff-8027038201cf07a6c96abf3cbf0b0f4fdd8a64ce6292435f01c8ed995b87fe9b) to compile. To do that we need to try to evaluate constants in `try_unify_abstract_consts`, this requires us to be more careful about what constants we try to resolve, specifically we cannot try to resolve constants that still contain inference variables. r? ``@lcnr``
Try to evaluate in try unify and postpone resolution of constants that contain inference variables We want code like that in [`ui/const-generics/generic_const_exprs/eval-try-unify.rs`](https://github.com/rust-lang/rust/compare/master...b-naber:eval-in-try-unify?expand=1#diff-8027038201cf07a6c96abf3cbf0b0f4fdd8a64ce6292435f01c8ed995b87fe9b) to compile. To do that we need to try to evaluate constants in `try_unify_abstract_consts`, this requires us to be more careful about what constants we try to resolve, specifically we cannot try to resolve constants that still contain inference variables. r? ```@lcnr```
@bors r- |
uhm seems spurious @bors r=lcnr |
📌 Commit 11a70db has been approved by |
Rollup of 5 pull requests Successful merges: - rust-lang#94391 (Fix ice when error reporting recursion errors) - rust-lang#94655 (Clarify which kinds of MIR are allowed during which phases.) - rust-lang#95179 (Try to evaluate in try unify and postpone resolution of constants that contain inference variables) - rust-lang#95270 (debuginfo: Fix debuginfo for Box<T> where T is unsized.) - rust-lang#95276 (add diagnostic items for clippy's `trim_split_whitespace`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
We want code like that in
ui/const-generics/generic_const_exprs/eval-try-unify.rs
to compile. To do that we need to try to evaluate constants intry_unify_abstract_consts
, this requires us to be more careful about what constants we try to resolve, specifically we cannot try to resolve constants that still contain inference variables.r? @lcnr