| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
5149: Implement Chalk variable kinds r=flodiebold a=flodiebold
This means we need to keep track of the kinds (general/int/float) of variables in `Canonical`, which requires some more ceremony. (It also exposes some places where we're not really dealing with canonicalization correctly -- another thing to be cleaned up when we switch to using Chalk's types directly.)
Should fix the last remaining issue of #2534.
Co-authored-by: Florian Diebold <[email protected]>
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This means we need to keep track of the kinds (general/int/float) of variables
in `Canonical`, which requires some more ceremony. (It also exposes some places
where we're not really dealing with canonicalization correctly -- another thing
to be cleaned up when we switch to using Chalk's types directly.)
Should fix the last remaining issue of #2534.
|
| |
| |
| |
| |
| |
| | |
This makes the intention of inherent vs. trait impls somewhat more
clear and also fixes (?) an issue where trait impls with an unresolved
trait were added as inherent impls instead (hence the test changes).
|
|/
|
|
|
| |
It creates a big map and duplicates lots of impls that are then left
lying around
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
'Unknown' int/float types actually never exist as such, they get replaced by
type variables immediately. So the whole `Uncertain<IntTy>` thing was
unnecessary and just led to a bunch of match branches that were never hit.
|
| |
|
|
|
|
|
| |
This also removes some vestiges of the old impl trait support which I think
aren't currently in use.
|
|
|
|
|
| |
This speeds up inference in analysis-stats by ~30% (even more with the recursive
solver).
|
|
|
|
|
|
|
| |
The big change here is counting binders, not
variables (https://github.com/rust-lang/chalk/pull/360). We have to adapt to the
same scheme for our `Ty::Bound`. It's mostly fine though, even makes some things
more clear.
|
| |
|
|
|
|
|
|
|
| |
It improves compile time in `--release` mode quite a bit, it doesn't
really slow things down and, conceptually, it seems closer to what we
want the physical architecture to look like (we don't want to
monomorphise EVERYTHING in a single leaf crate).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To test whether the receiver type matches for the impl, we unify the given self
type (in this case `HashSet<{unknown}>`) with the self type of the
impl (`HashSet<?0>`), but if the given self type contains Unknowns, they won't
be unified with the variables in those places. So we got a receiver type that
was different from the expected one, and concluded the impl doesn't match.
The fix is slightly hacky; if after the unification, our variables are still
there, we make them fall back to Unknown. This does make some sense though,
since we don't want to 'leak' the variables.
Fixes #3547.
|
|
|
|
|
|
|
| |
Basically, we need to allow variables in the caller self type to unify with the
impl's declared self type. That requires some more contortions in the variable
handling. I'm looking forward to (hopefully) handling this in a cleaner way when
we switch to Chalk's types and unification code.
|
| |
|
|
|
|
|
|
|
| |
It turns out rustc actually only unsizes array method receivers, so we don't
need to do any trait solving for this (at least for now).
Fixes #2670.
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes #3144.
|
| |
|
|
|
|
| |
don't belong
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The stand-alone `unify` requires that the type doesn't contain any type
variables. So we can't share the code here for now (without more refactoring)...
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
- impl Trait<Self> for S is allowed
- impl Trait for S<Self> is an invalid cycle, but we can add cycle recovery for
it in Salsa now
|
| |
|
|
|