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...)
It's not entirely clear what subnode ranges should mean in the
presence of macros, so let's leave them out for now. We are not using
them heavily anyway.
3996: Fix path for proc-macro in nightly / stable release r=matklad a=edwin0cheng
I messed up that I forget we use different executable names for nightly / stable release, I changed to use the current executable name instead.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
4008: tests: add more info about what failed in tidy tests r=matklad a=bnjjj
Separate PR from #3954
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
4007: Reduce allocations when looking up proc macro decl r=edwin0cheng a=lnicola
`libserde_derive` has about 21K symbols on Linux. It's not much, but let's ~~not be wasteful~~ avoid the allocations anyway.
r? @edwin0cheng
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
3958: Add proc-macro related config and tests r=matklad a=edwin0cheng
This PR do the following things:
1. Add cli argument `proc-macro` for running proc-macro server.
2. Added support for proc-macro in bench and analysis-stats
3. Added typescript config for proc-macros
4. Added an heavy test for proc-macros.
To test it out:
1. run `cargo xtask install --proc-macro`
2. add `"rust-analyzer.cargo.loadOutDirsFromCheck": true"` and `"rust-analyzer.procMacro.enabled": true"` in vs code config.
[Edit] Change to use `rust-analyzer proc-macro` for running proc-macro standalone process.
Co-authored-by: Edwin Cheng <edwin0cheng@gmail.com>
3979: fix missing match arm false positive for enum with no variants r=flodiebold a=JoshMcguigan
fixes#3974
Co-authored-by: Josh Mcguigan <joshmcg88@gmail.com>
3990: Switch to Chalk recursive solver r=matklad a=flodiebold
Before:
```
Expressions of unknown type: 5526 (3%)
Expressions of partially unknown type: 5415 (3%)
```
After:
```
Expressions of unknown type: 4600 (2%)
Expressions of partially unknown type: 4645 (2%)
```
On the other hand,
```
'./target/release/rust-analyzer analysis-stats -q . # old solver' ran
1.24 ± 0.04 times faster than 'rust-analyzer analysis-stats -q . # new solver'
```
I think part of this just comes from the fact that we're inferring more types now; but apart from that, it should be possible to improve the performance a bunch, and I'll make looking into that a priority.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
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>
3969: Change add_function assist to use todo!() instead of unimplemented!() r=matklad a=TimoFreiberg
In the spirit of #3935
Co-authored-by: Timo Freiberg <timo.freiberg@gmail.com>
