Don't flounder on int/float vars #555
Conversation
|
I've come to think that the recursive solver's approach, of asking for program clauses before instantiation, is more correct. We could just pass the canonical binders as well, so that it can inspect the variable kinds. |
I think a prerequisite for that would be to convert the SLG solver to also ask for clauses before instantiation, probably? Since it requires changing the interface to take a |
flodiebold
force-pushed
the
integer-var-floundering
branch
from
fc0ee17 to
a3b372c
Compare
|
@jackh726 @nikomatsakis here's a variant that works and avoids refactoring the SLG solver for now. It's slightly hacky, but maybe good enough until we can get the two solvers aligned? |
There was a problem hiding this comment.
So, the changes here are simple enough. I would like to think more about long term whether we do want to get program clauses before or after instantiation and why. I don't necessarily have a good opinion either way right now, so I'm curious to here about @nikomatsakis's thoughts.
In any case, I'm okay with merging this now with both a FIXME or comment added (probably in program_clauses_for_goal in clauses) about the use of binders. Also, I would like an issue filed for followup. @flodiebold feel free to merge after that
If the self type in our goal is e.g. an int var, we don't need to flounder even if the trait is non-enumerable because the search can still be restricted to a few types (rustc can do this already).
To achieve this, we pass the binders. It's slightly hacky; it would be nicer if we could just pass the `Canonical`, but that would require the SLG solver to pass a canonicalized goal, which it doesn't currently. So passing the binders separately feels slightly less bad.
flodiebold
force-pushed
the
integer-var-floundering
branch
from
a3b372c to
7c91b70
Compare
The impl search code needs to be able to tell that it's just looking for int/float impls.
|
Added the FIXME. I also realized that the |
|
Where does |
|
In rust-analyzer (or rustc, if it used the recursive solver). We need to know that we're actually looking for impls on integer or float types, so that we can search only those and not have to return all impls. |
|
I'll merge this now so we can use it in RA. Follow-up issue is #568. |
If the self type in our goal is e.g. an int var, we don't need to flounder even if the trait is non-enumerable because the search can still be restricted to a few types (rustc can do this already).
This works with the SLG solver, but the recursive solver passes goals to the program clauses code before instantiating them, and from just the BoundVars we can't tell their kind. Maybe we need to change the recursive solver to instantiate first after all? @nikomatsakis any ideas / suggestions?