This adds the type inference to Union types and add a small test case
for it, ensuring it keeps working in future.
Fixes: #5277
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
We need to add the `T: Index<Arg>` obligation to be resolved later as well,
otherwise we can't make inferences about `Arg` later based on the `Index` impls.
This still doesn't fix indexing with integer variables though; there's a further
problem with Chalk floundering because of the variable, I think.
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 <florian.diebold@freiheit.com>
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).
5124: (Partially) fix handling of type params depending on type params r=matklad a=flodiebold
If the first type parameter gets inferred, that's still not handled correctly; it'll require some more refactoring: E.g. if we have `Thing<T, F=fn() -> T>` and then instantiate `Thing<_>`, that gets turned into `Thing<_, fn() -> _>` before the `_` is instantiated into a type variable -- so afterwards, we have two type variables without any connection to each other.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
If the first type parameter gets inferred, that's still not handled correctly;
it'll require some more refactoring: E.g. if we have `Thing<T, F=fn() -> T>` and
then instantiate `Thing<_>`, that gets turned into `Thing<_, fn() -> _>` before
the `_` is instantiated into a type variable -- so afterwards, we have two type
variables without any connection to each other.
Move unsafe_expressions to unsafe_validation.rs, replace vec tracking of
child exprs with inline macro, add debug assert to ensure tracked
children match walked children exactly
5033: Order of glob imports should not affect import shadowing r=Nashenas88 a=Nashenas88
Fixes#5032
Co-authored-by: Paul Daniel Faria <Nashenas88@users.noreply.github.com>
4947: Replace `impls_in_trait` query with smarter use of `CrateImplDefs` r=matklad a=jonas-schievink
`impls_in_trait` was allocating a whopping ~400 MB of RAM when running analysis-stats on r-a itself.
Remove it, instead adding a query that computes a summary `CrateImplDefs` map for all transitive dependencies. This can probably still be made more efficient, but this already reduces the peak memory usage by 25% without much performance impact on analysis-stats.
**Before**:
```
Total: 34.962107188s, 2083mb allocated 2141mb resident
422mb ImplsForTraitQuery (deps)
250mb CrateDefMapQueryQuery
147mb MacroArgQuery
140mb TraitSolveQuery (deps)
68mb InferQueryQuery (deps)
62mb ImplDatumQuery (deps)
```
**After**:
```
Total: 35.261100358s, 1520mb allocated 1569mb resident
250mb CrateDefMapQueryQuery
147mb MacroArgQuery
144mb TraitSolveQuery (deps)
68mb InferQueryQuery (deps)
61mb ImplDatumQuery (deps)
45mb BodyQuery
45mb ImplDatumQuery
```
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
4958: Infer FnSig via Fn traits r=flodiebold a=adamrk
Addresses https://github.com/rust-analyzer/rust-analyzer/issues/4481.
When inferring types check if the callee implements one of the builtin `Fn` traits. Also autoderef the callee before trying to figure out it's `FnSig`.
Co-authored-by: adamrk <ark.email@gmail.com>
When referring to an associated type of a super trait, we used the substs of the
subtrait. That led to the #4931 crash if the subtrait had less parameters, but
it could also lead to other incorrectness if just the order was different.
Fixes#4931.
4851: Add quickfix to add a struct field r=TimoFreiberg a=TimoFreiberg
Related to #4563
I created a quickfix for record literals first because the NoSuchField diagnostic was already there.
To offer that quickfix for FieldExprs with unknown fields I'd need to add a new diagnostic (or create a `NoSuchField` diagnostic for those cases)
I think it'd make sense to make this a snippet completion (to select the generated type), but this would require changing the `Analysis` API and I'd like some feedback before I touch that.
Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
'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.
4689: Implement return position impl trait / opaque type support r=matklad a=flodiebold
This is working, but I'm not that happy with how the lowering works. We might need an additional representation between `TypeRef` and `Ty` where names are resolved and `impl Trait` bounds are separated out, but things like inference variables don't exist and `impl Trait` is always represented the same way.
Also note that this doesn't implement correct handling of RPIT *inside* the function (which involves turning the `impl Trait`s into variables and creating obligations for them). That intermediate representation might help there as well.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Co-authored-by: Florian Diebold <florian.diebold@freiheit.com>
This is working, but I'm not that happy with how the lowering works. We might
need an additional representation between `TypeRef` and `Ty` where names are
resolved and `impl Trait` bounds are separated out, but things like inference
variables don't exist and `impl Trait` is always represented the same
way.
Also note that this doesn't implement correct handling of RPIT *inside* the
function (which involves turning the `impl Trait`s into variables and creating
obligations for them). That intermediate representation might help there as
well.
