4023: Fix another crash from wrong binders r=matklad a=flodiebold
Basically, if we had something like `dyn Trait<T>` (where `T` is a type parameter) in an impl we lowered that to `dyn Trait<^0.0>`, when it should be `dyn Trait<^1.0>` because the `dyn` introduces a new binder. With one type parameter, that's just wrong, with two, it'll lead to crashes.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Basically, if we had something like `dyn Trait<T>` (where `T` is a type
parameter) in an impl we lowered that to `dyn Trait<^0.0>`, when it should be
`dyn Trait<^1.0>` because the `dyn` introduces a new binder. With one type
parameter, that's just wrong, with two, it'll lead to crashes.
Fixes a lot of false type mismatches.
(And as always when touching the unification code, I have to say I'm looking
forward to replacing it by Chalk's...)
3966: Add support for bounds on associated types in trait definitions r=matklad a=flodiebold
E.g.
```rust
trait Trait {
type Item: SomeOtherTrait;
}
```
Note that these don't simply desugar to where clauses; as I understand it, where clauses have to be proved by the *user* of the trait, but these bounds are proved by the *implementor*. (Also, where clauses on associated types are unstable.)
(Another one from my recursive solver branch...)
3968: Remove format from syntax_bridge hot path r=matklad a=edwin0cheng
Although only around 1% speed up by running:
```
Measure-Command {start-process .\target\release\rust-analyzer "analysis-stats -q ." -NoNewWindow -wait}
```
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3964: Nicer Chalk debug logs r=matklad a=flodiebold
I'm looking at a lot of Chalk debug logs at the moment, so here's a few changes to make them slightly nicer...
3965: Implement inline associated type bounds r=matklad a=flodiebold
Like `Iterator<Item: SomeTrait>`.
This is an unstable feature, but it's used in the standard library e.g. in the definition of Flatten, so we can't get away with not implementing it :)
(This is cherry-picked from my recursive solver branch, where it works better, but I did manage to write a test that works with the current Chalk solver as well...)
3967: Handle `Self::Type` in trait definitions when referring to own associated type r=matklad a=flodiebold
It was implemented for other generic parameters for the trait, but not for `Self`.
(Last one off my recursive solver branch 😄 )
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
E.g.
```
trait Trait {
type Item: SomeOtherTrait;
}
```
Note that these don't simply desugar to where clauses; as I understand it, where
clauses have to be proved by the *user* of the trait, but these bounds are proved
by the *implementor*. (Also, where clauses on associated types are unstable.)
Like `Iterator<Item: SomeTrait>`.
This is an unstable feature, but it's used in the standard library e.g. in the
definition of Flatten, so we can't get away with not implementing it :)
We treat macro calls as expressions (there's appropriate Into impl),
which causes problem if there's expresison and non-expression macro in
the same node (like in the match arm).
We fix this problem by nesting macor patterns into another node (the
same way we nest path into PathExpr or PathPat). Ideally, we probably
should add a similar nesting for macro expressions, but that needs
some careful thinking about macros in blocks: `{ am_i_expression!() }`.
To do this we need to carry around the original resolution a bit, because `Self`
gets resolved to the actual type immediately, but you're not allowed to write
the equivalent type in a projection. (I tried just comparing the projection base
type with the impl self type, but that seemed too dirty.) This is basically how
rustc does it as well.
Fixes#3249.
3494: Implement include macro r=matklad a=edwin0cheng
This PR implement builtin `include` macro.
* It does not support include as expression yet.
* It doesn't consider `env!("OUT_DIR")` yet.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3385: Fix#3373 r=matklad a=flodiebold
Basically, we need to allow variables in the caller self type to unify with the
impl's declared self type. That requires some more contortions in the variable
handling. I'm looking forward to (hopefully) handling this in a cleaner way when
we switch to Chalk's types and unification code.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Basically, we need to allow variables in the caller self type to unify with the
impl's declared self type. That requires some more contortions in the variable
handling. I'm looking forward to (hopefully) handling this in a cleaner way when
we switch to Chalk's types and unification code.
E.g. for `&{ some_string() }` in a context where a `&str` is expected, we
reported a mismatch inside the block. The problem is that we're passing an
expectation of `str` down, but the expectation is more of a hint in this case.
There's a long comment in rustc about this, which I just copied.
Also, fix reported location for type mismatches in macros.
E.g. in `match x { None => ... }`, `None` is a path pattern (resolving to the
option variant), not a binding. To determine this, we need to try to resolve the
name during lowering. This isn't too hard since we already need to resolve names
for macro expansion anyway (though maybe a bit hacky).
Fixes#1618.
