| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
4175: Introduce HirDisplay method for rendering source code & use it in add_function assist r=flodiebold a=TimoFreiberg
Next feature for #3639.
So far the only change in the new `HirDisplay` method is that paths are qualified, but more changes will be necessary (omitting the function name from function types, returning an error instead of printing `"{unknown}"`, probably more).
Is that approach okay?
Co-authored-by: Timo Freiberg <[email protected]>
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
E.g. in
```rust
match x {
1 => function1,
2 => function2,
}
```
we need to try coercing both to pointers. Turns out this is a special case in
rustc as well (see the link in the comment).
|
| | |
| |
| |
| |
| | |
Still no break-with-value or labels, but at least we know that `loop { break; }`
doesn't diverge.
|
| |/
|
|
|
|
|
|
| |
Divergence here means that for some reason, the end of a block will not be
reached. We tried to model this just using the never type, but that doesn't work
fully (e.g. in `let x = { loop {}; "foo" };` x should still have type `&str`);
so this introduces a `diverges` flag that the type checker keeps track of, like
rustc does.
|
| |
|
|
| |
They're `&[u8; N]`, not `&[u8]` (see #4374).
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| | |
4305: Favor types for record type struct in name resolution r=matklad a=edwin0cheng
Fixed #4235
Co-authored-by: Edwin Cheng <[email protected]>
|
| | | |
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
4234: Support local_inner_macros r=jonas-schievink a=edwin0cheng
This PR implements `#[macro_export(local_inner_macros)]` support.
Note that the rustc implementation is quite [hacky][1] too. :)
[1]: https://github.com/rust-lang/rust/blob/614f273e9388ddd7804d5cbc80b8865068a3744e/src/librustc_resolve/macros.rs#L456
Co-authored-by: Edwin Cheng <[email protected]>
|
| | | |
|
| | | |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
4173: Use core instead of std for builtin derive macros r=edwin0cheng a=edwin0cheng
Fixed #4087.
We can't use `$crate` here right now because :
1. We have to able to detect `macro` 2.0 in collecting phase for finding `rustc_builtin_macro` attrs.
2. And we have to make hygiene works for builtin derive macro.
r= @flodiebold
Co-authored-by: Edwin Cheng <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
| |
So e.g. if we have `fn foo<T: SomeTrait<u32>>() -> T::Item`, we want to lower
that to `<T as SomeTrait<u32>>::Item` and not `<T as SomeTrait<_>>::Item`.
|
| | |
|
| |
|
|
|
|
|
| |
We need to shift in when we're substituting inside a binder.
This should fix #4053 (it doesn't fix the occasional overflow that also occurs
on the Diesel codebase though).
|
| |
|
|
|
|
|
| |
The root cause was that we forgot to add bindings from the arm to the
guard expression
closes #3980
|
| |\
| |
| |
| |
| |
| |
| |
| | |
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 <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| | |
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...)
|
| | | |
|
| |/ |
|
| | |
|
| |
|
|
| |
+ various fixes related to that.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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 <[email protected]>
Co-authored-by: Edwin Cheng <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.)
|
| | | | | |
| | \ \ | |
| |\ \ \ \
| |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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 :smile: )
Co-authored-by: Florian Diebold <[email protected]>
|
| | |/ /
|/| |
| | |
| | | |
It was implemented for other generic parameters for the trait, but not for `Self`.
|
| |/ /
| |
| |
| |
| |
| |
| | |
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 :)
|
| |/
|
|
|
|
| |
The grammar now looks like this
[name_ref :] pat
|
| | |
|
| |
|
|
|
| |
Fixes #3865. Basically I forgot to shift 'back' when we got `dyn Trait`s back
from Chalk, so after going through Chalk a few times, the panic happened.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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!() }`.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
