5004: Fix panic in split/merge import assists r=matklad a=lnicola
Fixes#4368#4905
Not sure if this is the best solution here. Maybe the `make` functions should be fallible? We generally seem to be playing whack-a-mole with panics in assists, although most of them are `unwrap`s in the assist code.
Co-authored-by: Laurențiu Nicola <lnicola@dend.ro>
5002: Fix underflow panic when doctests are at top of file r=Nashenas88 a=Nashenas88
While debugging a comment at the top of a test string, I discovered that the offset calculations could underflow and panic. This only seemed to occur in tests, I assume because it's running a debug mode. The wrapping is quickly fixed later on in release mode, which is why this seems to have gone unnoticed. The new checks ensure the value is always positive or zero.
Co-authored-by: Paul Daniel Faria <nashenas88@users.noreply.github.com>
4999: SSR: Allow matching of whole macro calls r=matklad a=davidlattimore
Matching within macro calls is to come later and matching of macro calls within macro calls later still.
Co-authored-by: David Lattimore <dml@google.com>
5000: Remove RelativePathBuf from fixture r=matklad a=matklad
The paths in fixture are not really relative (the default one is
`/main.rs`), so it doesn't make sense to use `RelativePathBuf` here.
bors r+
🤖
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
4900: Self variant enum res fix r=BGluth a=BGluth
Fixes#4789.
This is my first PR for this project, so it's probably worth giving it an extra close look.
A few things that I wasn't sure about:
- Is `resolve_path` really the best place to perform this check? It seemed like a natural place, but perhaps there's a better place?
- When handling the new variant `PathResolution::VariantDef`, I couldn't see an obvious variant of `TypeNs` to return in `in_type_ns` for Unions and Structs.
Co-authored-by: BGluth <gluthb@gmail.com>
4921: Allow SSR to match type references, items, paths and patterns r=davidlattimore a=davidlattimore
Part of #3186
Co-authored-by: David Lattimore <dml@google.com>
4947: Replace `impls_in_trait` query with smarter use of `CrateImplDefs` r=matklad a=jonas-schievink
`impls_in_trait` was allocating a whopping ~400 MB of RAM when running analysis-stats on r-a itself.
Remove it, instead adding a query that computes a summary `CrateImplDefs` map for all transitive dependencies. This can probably still be made more efficient, but this already reduces the peak memory usage by 25% without much performance impact on analysis-stats.
**Before**:
```
Total: 34.962107188s, 2083mb allocated 2141mb resident
422mb ImplsForTraitQuery (deps)
250mb CrateDefMapQueryQuery
147mb MacroArgQuery
140mb TraitSolveQuery (deps)
68mb InferQueryQuery (deps)
62mb ImplDatumQuery (deps)
```
**After**:
```
Total: 35.261100358s, 1520mb allocated 1569mb resident
250mb CrateDefMapQueryQuery
147mb MacroArgQuery
144mb TraitSolveQuery (deps)
68mb InferQueryQuery (deps)
61mb ImplDatumQuery (deps)
45mb BodyQuery
45mb ImplDatumQuery
```
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
4958: Infer FnSig via Fn traits r=flodiebold a=adamrk
Addresses https://github.com/rust-analyzer/rust-analyzer/issues/4481.
When inferring types check if the callee implements one of the builtin `Fn` traits. Also autoderef the callee before trying to figure out it's `FnSig`.
Co-authored-by: adamrk <ark.email@gmail.com>
When referring to an associated type of a super trait, we used the substs of the
subtrait. That led to the #4931 crash if the subtrait had less parameters, but
it could also lead to other incorrectness if just the order was different.
Fixes#4931.
