aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_hir/src/ty.rs
Commit message (Collapse)AuthorAgeFilesLines
* remove forward pointer for type_refAleksey Kladov2019-10-301-2/+2
|
* make_mut_sliceShotaro Yamada2019-10-141-16/+10
|
* `.collect()` directly into `Arc<[T]>`Shotaro Yamada2019-10-141-4/+2
|
* Avoid cloning `Arc<[T]>` into a vec if possibleShotaro Yamada2019-10-141-19/+17
|
* Add SubstsBuilderFlorian Diebold2019-09-261-6/+135
| | | | + further refactoring.
* Avoid intermediate allocationShotaro Yamada2019-09-251-1/+1
|
* Give closures typesFlorian Diebold2019-09-241-1/+22
|
* Handle associated type shorthand (`T::Item`)Florian Diebold2019-09-221-2/+2
| | | | | | | | | | | | This is only allowed for generic parameters (including `Self` in traits), and special care needs to be taken to not run into cycles while resolving it, because we use the where clauses of the generic parameter to find candidates for the trait containing the associated type, but the where clauses may themselves contain instances of short-hand associated types. In some cases this is even fine, e.g. we might have `T: Trait<U::Item>, U: Iterator`. If there is a cycle, we'll currently panic, which isn't great, but better than overflowing the stack...
* Upgrade ChalkFlorian Diebold2019-09-141-45/+0
| | | | ... and remove Ty::UnselectedProjection. It'll be handled differently.
* rename AdtDef -> AdtAleksey Kladov2019-09-121-6/+6
|
* Make type walking infrastructure a bit nicerFlorian Diebold2019-09-031-113/+120
| | | | | If/when we switch to using Chalk's Ty, we'll need to replace this by its `Fold` trait, but I didn't want to import the whole thing just yet.
* Properly format `impl Trait<Type = Foo>` typesFlorian Diebold2019-09-031-19/+93
| | | | | | It's a bit complicated because we basically have to 'undo' the desugaring, and the result is very dependent on the specifics of the desugaring and will probably produce weird results otherwise.
* Add support for associated type bindings (`where Trait<Type = X>`)Florian Diebold2019-09-031-0/+33
|
* Handle impl/dyn Trait in method resolutionFlorian Diebold2019-08-221-0/+13
| | | | | | | | | | | | | When we have one of these, the `Trait` doesn't need to be in scope to call its methods. So we need to consider this when looking for method candidates. (Actually I think the same is true when we have a bound `T: some::Trait`, but we don't handle that yet). At the same time, since Chalk doesn't handle these types yet, add a small hack to skip Chalk in method resolution and just consider `impl Trait: Trait` always true. This is enough to e.g. get completions for `impl Trait`, but since we don't do any unification we won't infer the return type of e.g. `impl Into<i64>::into()`.
* Add `impl Trait` and `dyn Trait` typesFlorian Diebold2019-08-221-10/+110
| | | | | | | - refactor bounds handling in the AST a bit - add HIR for bounds - add `Ty::Dyn` and `Ty::Opaque` variants and lower `dyn Trait` / `impl Trait` syntax to them
* Improve debug logging a bitFlorian Diebold2019-08-121-0/+14
|
* Add representations of associated typesFlorian Diebold2019-08-121-0/+86
| | | | | | | | | | | | This adds three different representations, copied from the Chalk model: - `Ty::Projection` is an associated type projection written somewhere in the code, like `<Foo as Trait>::Bar`. - `Ty::UnselectedProjection` is similar, but we don't know the trait yet (`Foo::Bar`). - The above representations are normalized to their actual types during type inference. When that isn't possible, for example for `T::Item` inside an `fn foo<T: Iterator>`, the type is normalized to an application type with `TypeCtor::AssociatedType`.
* provide completion in struct patternsEkaterina Babshukova2019-07-211-1/+1
|
* Some renamings for clarityFlorian Diebold2019-07-141-1/+1
|
* Unify `normalize` and `implements` to simplify codeFlorian Diebold2019-07-081-1/+1
|
* Refactor a bit & introduce Environment structFlorian Diebold2019-07-081-1/+1
|
* Add trait obligations for where clauses when calling functions/methodsFlorian Diebold2019-07-061-2/+2
| | | | | E.g. if we call `foo<T: Into<u32>>(x)`, that adds an obligation that `x: Into<u32>`, etc.
* allow rustfmt to reorder importsAleksey Kladov2019-07-041-5/+8
| | | | | | This wasn't a right decision in the first place, the feature flag was broken in the last rustfmt release, and syntax highlighting of imports is more important anyway
* Simplifications / cleanup from reviewFlorian Diebold2019-06-161-0/+1
|
* Somewhat handle variables in the derefed type, and add another testFlorian Diebold2019-06-151-0/+11
|
* Implement autoderef using the Deref traitFlorian Diebold2019-06-151-2/+3
| | | | - add support for other lang item targets, since we need the Deref lang item
* Add basic infrastructure for assoc type projectionFlorian Diebold2019-06-151-1/+10
|
* Fix clippy::or_fun_callAlan Du2019-06-041-1/+1
|
* add union to code_modelAleksey Kladov2019-05-231-0/+1
|
* profile type inferenceAleksey Kladov2019-05-211-1/+1
|
* Add infer for generic default typeEdwin Cheng2019-05-191-1/+1
|
* Handle where clauses in trait solvingFlorian Diebold2019-05-111-1/+30
|
* Add a HirDisplay implementation for TraitRefFlorian Diebold2019-05-071-0/+17
|
* Turn `implements` into a query againFlorian Diebold2019-05-071-1/+1
|
* Differentiate Tuple / FnPtr type constructors by cardinalityFlorian Diebold2019-05-041-7/+9
| | | | | This is necessary because Chalk (reasonably) expects each 'struct' to know how many type parameters it takes.
* Simplify subst / subst_bound_vars a bitFlorian Diebold2019-05-041-12/+2
|
* Canonicalize before doing method resolutionFlorian Diebold2019-05-041-0/+11
|
* Implement Deref<Target=[Ty]> for SubstsFlorian Diebold2019-05-041-17/+18
|
* Chalk integrationFlorian Diebold2019-05-041-1/+48
| | | | | - add proper canonicalization logic - add conversions from/to Chalk IR
* Add Ty::Bound variant for use in Chalk integrationFlorian Diebold2019-05-041-2/+7
|
* Make callable signature handling a bit nicerFlorian Diebold2019-04-141-0/+22
|
* More trait infrastructureFlorian Diebold2019-04-141-0/+11
| | | | | | | | | | - make it possible to get parent trait from method - add 'obligation' machinery for checking that a type implements a trait (and inferring facts about type variables from that) - handle type parameters of traits (to a certain degree) - improve the hacky implements check to cover enough cases to exercise the handling of traits with type parameters - basic canonicalization (will probably also be done by Chalk)
* Make call info to use real name resolutionAleksey Kladov2019-04-111-2/+12
|
* Added ArrayExprKind,Lenard Pratt2019-04-071-1/+1
| | | | | changed the display for fixed array types, Added Array Enum to ra_hir/expr
* Added inference of array lengthLenard Pratt2019-04-071-1/+5
|
* Implement a very naive implements checkFlorian Diebold2019-03-251-4/+19
| | | | ... to make the infer_trait_method_simple test have the correct result.
* Assert in apply_substs that the number of parameters doesn't changeFlorian Diebold2019-03-211-1/+6
| | | | ... and fix a small bug revealed by that.
* Rename name field to ctor as wellFlorian Diebold2019-03-211-14/+14
|
* Some more doc commentsFlorian Diebold2019-03-211-2/+12
|
* TypeName => TypeCtorFlorian Diebold2019-03-211-24/+24
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-05 01:59:07 +0000