aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_hir_ty
Commit message (Collapse)AuthorAgeFilesLines
* Rudimentary name resolution for local itemsAleksey Kladov2019-12-221-6/+6
|
* Merge #2626bors[bot]2019-12-211-0/+23
|\ | | | | | | | | | | | | | | 2626: Recursive collect macros in impl items r=matklad a=edwin0cheng Co-authored-by: Edwin Cheng <[email protected]>
| * Recursive collect macros in impl itemsEdwin Cheng2019-12-201-0/+23
| |
* | Merge #2625bors[bot]2019-12-212-3/+3
|\ \ | |/ |/| | | | | | | | | | | 2625: Clippy lints r=matklad a=kjeremy Co-authored-by: kjeremy <[email protected]>
| * Clippy lintskjeremy2019-12-202-3/+3
| |
* | Merge #2624bors[bot]2019-12-203-3/+3
|\ \ | | | | | | | | | | | | | | | | | | | | | 2624: Separate module item from module scope r=matklad a=matklad bors r+ Co-authored-by: Aleksey Kladov <[email protected]>
| * | Move impls to ItemScopeAleksey Kladov2019-12-203-3/+3
| | |
* | | Merge #2623bors[bot]2019-12-201-0/+19
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | 2623: Add support macros in impl blocks r=matklad a=edwin0cheng This PR add support for macros in impl blocks, which reuse `Expander` for macro expansion. see also: #2459 Co-authored-by: Edwin Cheng <[email protected]>
| * | Add support macros in impl blocksEdwin Cheng2019-12-201-0/+19
| |/
* | Coerce closures to fn pointersFlorian Diebold2019-12-203-5/+48
| | | | | | | | E.g. `let x: fn(A) -> B = |x| { y };`
* | Fix coercion of last expression in function bodyFlorian Diebold2019-12-203-2/+18
| |
* | Handle closure return typesFlorian Diebold2019-12-204-4/+106
|/ | | | Fixes #2547.
* Merge #2592bors[bot]2019-12-203-5/+59
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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]>
| * Use fill instread of for loopEdwin Cheng2019-12-191-5/+3
| |
| * Use build_for_defEdwin Cheng2019-12-191-1/+1
| |
| * Add std::ops::Index support for inferingEdwin Cheng2019-12-193-5/+61
| |
* | Use generic ItemLoc for implsAleksey Kladov2019-12-202-2/+2
| |
* | Support for nested traitsAleksey Kladov2019-12-201-2/+4
| |
* | Support for nested ADTAleksey Kladov2019-12-201-2/+2
| |
* | Introduce `ContainerId`Aleksey Kladov2019-12-203-3/+3
| |
* | Rename ContainerId -> AssocContainerIdAleksey Kladov2019-12-206-22/+22
| |
* | Add body as a possible container for itemsAleksey Kladov2019-12-193-7/+7
| |
* | Remove TruncateOptions structKirill Bulatov2019-12-191-13/+10
| |
* | Omit default parameter typesKirill Bulatov2019-12-192-7/+47
| |
* | Forbid <T>::foo syntax in mod pathsAleksey Kladov2019-12-182-5/+5
|/
* Add test markFlorian Diebold2019-12-153-2/+9
|
* Handle impl Trait more correctlyFlorian Diebold2019-12-153-1/+56
| | | | | | | 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.
* Add test for unifying impl TraitFlorian Diebold2019-12-151-1/+27
|
* Use different types for path with and without genericsAleksey Kladov2019-12-144-51/+51
|
* Use path macroFlorian Diebold2019-12-132-15/+15
|
* Rename N! to name!Florian Diebold2019-12-135-15/+15
|
* Add macros for known names and pathsFlorian Diebold2019-12-135-17/+15
|
* Correctly infer - and ! using std::ops::{Neg,Not}Emil Lauridsen2019-12-133-23/+104
|
* Add helper for resolving associated type of trait in inferEmil Lauridsen2019-12-132-47/+25
|
* Move enum&union to new locAleksey Kladov2019-12-121-4/+5
|
* Move structs to new locAleksey Kladov2019-12-121-1/+1
|
* Move traits to the new locAleksey Kladov2019-12-121-4/+2
|
* Switch to the new location for implsAleksey Kladov2019-12-122-4/+4
|
* chore: bump deps and use mainline chalkLaurențiu Nicola2019-12-091-3/+3
|
* Fix coercion from &Foo to an inference variable in a referenceFlorian Diebold2019-12-082-1/+42
| | | | We didn't try to unify within the reference, but we should.
* Merge #2466bors[bot]2019-12-081-0/+29
|\ | | | | | | | | | | | | | | | | | | | | 2466: Handle partial resolve cases r=matklad a=edwin0cheng Another try to fix #2443 : We resolve all imports every time in `DefCollector::collect` loop even it is resolved previously. This is because other unresolved imports and macros will bring in another `PerNs`, so we can only assume that it has been partially resolved. Co-authored-by: Edwin Cheng <[email protected]>
| * Add testsEdwin Cheng2019-12-061-0/+29
| |
* | Rename GenericParam -> TypeParamAleksey Kladov2019-12-071-14/+12
| | | | | | | | We don't have LifetimeParam yet, but they are planned!
* | ReformatAleksey Kladov2019-12-071-2/+2
| |
* | Refactor parameter count trackingAleksey Kladov2019-12-076-32/+30
| |
* | Remove idx and parent generics from genericsAleksey Kladov2019-12-076-60/+135
| | | | | | | | | | 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
| |
* | Merge #2484bors[bot]2019-12-061-3/+5
|\ \ | |/ |/| | | | | | | | | | | | | | | 2484: DynMap r=matklad a=matklad Implement a `DynMap` a semi-dynamic, semi-static map, which helps to thread heterogeneously typed info in a uniform way. Totally inspired by https://github.com/JetBrains/kotlin/blob/df3bee30384787d8951ea548a4257c2cb52a16a3/compiler/frontend/src/org/jetbrains/kotlin/resolve/BindingContext.java. @flodiebold wdyt? Seems like a potentially useful pattern for various source-map-like things. Co-authored-by: Aleksey Kladov <[email protected]>
| * DynMapAleksey Kladov2019-12-061-3/+5
| | | | | | | | | | This might, or might not help us to reduce boilerplate associated with plumbing values from analysis to the IDE layer
* | Don't unify within a referenceFlorian Diebold2019-12-063-11/+72
|/ | | | | | | 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.