-
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
Canonicalize inputs to const eval where needed #68505
Canonicalize inputs to const eval where needed #68505
Conversation
This comment has been minimized.
This comment has been minimized.
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.
LGTM, but I'll leave the approval to @nikomatsakis.
let mut query_state = OriginalQueryValues::default(); | ||
let canonical = self.canonicalize_query(&(param_env, substs), &mut query_state); | ||
let (param_env, substs) = canonical.value; | ||
self.tcx.const_eval_resolve(param_env, def_id, substs, promoted, span) |
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.
Wait, I just remembered something: you need to replace the type with the original one, if you want to return the value (since it's not used, you could just opt to return Result<(), ...>
for now).
This is because you don't want the canonical variables to stick around in the type.
There's also a related trick I've told @nikomatsakis about before:
The value produced by const-eval shouldn't depend on lifetimes, so we should probably always erase them in the input substs
(and param_env
even?).
But the type might have relevant lifetimes, which means we should (just like in the canonical case) use the original type along the new value.
I believe both canonicalizing and erasing lifetimes, would produce the correct value, but erasing them would result in perhaps better cache utilization.
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.
Ideally, canonicalization would replace all lifetimes and hence be the same, from a cache perspective, but we may not currently handle things that way (we may treat 'static
as special or something...)
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 would think erasing lifetimes would also be benefical for const eval queries which don't use canonicalization, i.e. the ones that don't use InferCtxt::const_eval_reolve
, although in most cases they already probably have there regions erased. It does look like canonicalize_query
, which i'm using, does replace `static lifetimes.
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.
But the type might have relevant lifetimes, which means we should (just like in the canonical case) use the original type along the new value.
Most usage of const-eval is by codegen or inside miri which doesn't need/want lifetimes, and in other cases the caller knows what type it's expecting, so I think it should be up to the callers to the replace the type if they need to. One place I'm unsure about is:
match self.tcx.const_eval_resolve( |
I'm not sure if lifetimes are important here or not, if they are I can replace the type with the node type retrieved above.
Welp this is definitely shorter =) It seems like we should do a perf run, though, right? |
@bors try |
⌛ Trying commit 0f12888bfeab463a0e1278c13ea8869f49bdd559 with merge ed91a52f6d36d06eaf36de547fda2e61d41780af... |
@rust-timer queue |
Awaiting bors try build completion |
☀️ Try build successful - checks-azure |
Queued ed91a52f6d36d06eaf36de547fda2e61d41780af with parent c2d141d, future comparison URL. |
Finished benchmarking try commit ed91a52f6d36d06eaf36de547fda2e61d41780af, comparison URL. |
b9ae8b1
to
c8e35e3
Compare
Can I get another perf run to see if erasing lifetimes has any effect on performance? |
@bors try |
Awaiting bors try build completion |
⌛ Trying commit c8e35e3df4016e72bf7eb3a1508a592a80d1f3ae with merge d7a172c31012c265a79fc422a27e2b8e35978ff3... |
☀️ Try build successful - checks-azure |
Queued d7a172c31012c265a79fc422a27e2b8e35978ff3 with parent 8bf1758, future comparison URL. |
Perf numbers looks like just noise. |
c8e35e3
to
b426c05
Compare
This actually now does fix #68477, as we are now erasing lifetimes of all inputs to const-eval, including region inference variables. |
What's the status of this PR? |
This is waiting for a review by @nikomatsakis, who has been at the Mozilla All Hands this week, so I imagine it'll be reviewed next week. |
☔ The latest upstream changes (presumably #68461) made this pull request unmergeable. Please resolve the merge conflicts. |
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.
This seems good to me. My only hesitation is that I can't quite tell what was going on with the erase-regions question, I guess maybe I need to dig a bit deeper there to form an opinion?
Hi, what's the status of this PR? |
I think the status is that we are waiting for @Skinny121 to do the following:
|
2e8fe60
to
1961b1b
Compare
☔ The latest upstream changes (presumably #67953) made this pull request unmergeable. Please resolve the merge conflicts. |
Change const eval to just return the value As discussed in rust-lang#68505 (comment), the type of consts shouldn't be returned from const eval queries. r? @eddyb cc @nikomatsakis
1961b1b
to
ebfa2f4
Compare
Should be ready for code review again. #69181 changed the return type of const eval queries to just the value as requested, as a result the changes to |
@Skinny121 if I understood correctly, this means my comments about refactoring the substitution code is no longer relevant, but @eddyb's concern around erasing regions is still relevant, right? Any thoughts on fixing that as they suggested? |
@nikomatsakis That concern isn't relevant any more as the erased regions don't escape that function, as |
@bors r+ |
📌 Commit ebfa2f4 has been approved by |
☀️ Test successful - checks-azure |
Canonicalize inputs to const eval, so that they can contain inference variables. Which enables invoking const eval queries even if the current param env has inference variable within it, which can occur during trait selection.
This is a reattempt of #67717, in a far less invasive way.
Fixes #68477
r? @nikomatsakis
cc @eddyb