aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_hir_ty/src/infer/expr.rs
Commit message (Collapse)AuthorAgeFilesLines
* Fix inference for shift operatorsFlorian Diebold2020-01-171-2/+2
| | | | Fixes #2602.
* Push resolver further upAleksey Kladov2020-01-141-6/+13
|
* Fix coercion of last expression in function bodyFlorian Diebold2019-12-201-1/+1
|
* Handle closure return typesFlorian Diebold2019-12-201-3/+14
| | | | Fixes #2547.
* Merge #2592bors[bot]2019-12-201-4/+8
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 2592: Add std::ops::Index support for infering r=edwin0cheng a=edwin0cheng see also #2534 Seem like this can't fix #2534 for this case: ```rust fn foo3(bar: [usize; 2]) { let baz = bar[1]; // <--- baz is still unknown ? println!("{}", baz); } ``` Co-authored-by: Edwin Cheng <[email protected]>
| * Add std::ops::Index support for inferingEdwin Cheng2019-12-191-4/+8
| |
* | Rename ContainerId -> AssocContainerIdAleksey Kladov2019-12-201-2/+2
|/
* Handle impl Trait more correctlyFlorian Diebold2019-12-151-0/+1
| | | | | | | When calling a function, argument-position impl Trait is transparent; same for return-position impl Trait when inside the function. So in these cases, we need to represent that type not by `Ty::Opaque`, but by a type variable that can be unified with whatever flows into there.
* Rename N! to name!Florian Diebold2019-12-131-2/+2
|
* Add macros for known names and pathsFlorian Diebold2019-12-131-2/+2
|
* Correctly infer - and ! using std::ops::{Neg,Not}Emil Lauridsen2019-12-131-21/+26
|
* Add helper for resolving associated type of trait in inferEmil Lauridsen2019-12-131-47/+7
|
* Refactor parameter count trackingAleksey Kladov2019-12-071-10/+8
|
* Remove idx and parent generics from genericsAleksey Kladov2019-12-071-11/+13
| | | | | This makes `hir_def::GenericParams` flatter. The logic for re-numbering the params is moved to hir instead.
* Store GenericParams in arenaAleksey Kladov2019-12-071-1/+1
|
* Don't unify within a referenceFlorian Diebold2019-12-061-11/+10
| | | | | | | If we are expecting a `&Foo` and get a `&something`, when checking the `something`, we are *expecting* a `Foo`, but we shouldn't try to unify whatever we get with that expectation, because it could actually be a `&Foo`, and `&&Foo` coerces to `&Foo`. So this fixes quite a few false type mismatches.
* Extract unification code to unify moduleFlorian Diebold2019-12-021-15/+15
|
* Reduce variants of Exproxalica2019-11-291-39/+37
|
* Infer range typesoxalica2019-11-281-0/+41
|
* Move TyAleksey Kladov2019-11-271-0/+686