| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
+ further refactoring.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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...
|
|
|
|
| |
... and remove Ty::UnselectedProjection. It'll be handled differently.
|
| |
|
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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()`.
|
|
|
|
|
|
|
| |
- 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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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`.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
E.g. if we call `foo<T: Into<u32>>(x)`, that adds an obligation that `x:
Into<u32>`, etc.
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
|
|
|
| |
- add support for other lang item targets, since we need the Deref lang item
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This is necessary because Chalk (reasonably) expects each 'struct' to know how
many type parameters it takes.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
- add proper canonicalization logic
- add conversions from/to Chalk IR
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
- 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)
|
| |
|
|
|
|
|
| |
changed the display for fixed array types,
Added Array Enum to ra_hir/expr
|
| |
|
|
|
|
| |
... to make the infer_trait_method_simple test have the correct result.
|
|
|
|
| |
... and fix a small bug revealed by that.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
It doesn't need to be in there since it's just information from the def. Another
step towards aligning Ty with Chalk's representation.
|