8245: Properly resolve intra doc links in hover and goto_definition r=matklad a=Veykril
Unfortunately involves a bit of weird workarounds due to pulldown_cmark's incorrect lifetimes on `BrokenLinkCallback`... I should probably open an issue there asking for the fixes to be pushed to a release since they already exist in the repo for quite some time it seems.
Fixes#8258, Fixes#8238
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
8326: Rewrite reorder fields assist to use mutable syntax trees r=matklad a=Veykril
This also instead uses `Either` to use the typed `RecordPat` and `RecordExpr` nodes, this unfortunately gives a bit of code duplication
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
8334: Intern and shrink more data to reduce memory usage r=jonas-schievink a=jonas-schievink
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8333: analysis-stats: allow skipping type inference r=jonas-schievink a=jonas-schievink
This removes "noise" from memory profiles since it avoids lowering
function bodies and types
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8332: Error when `rustfmt` component is unavailable r=jonas-schievink a=jonas-schievink
Fixes https://github.com/rust-analyzer/rust-analyzer/issues/8331
When the toolchain has no installable rustfmt component, running `rustfmt` complains with
```
error: the 'rustfmt' component which provides the command 'rustfmt' is not available for the 'nightly-2021-04-04-x86_64-unknown-linux-gnu' toolchain
```
Check for occurrence of "not available" in addition to the existing "not installed" to detect this case and report a user-visible error.
rustfmt and/or rustup should *really* be changed to not use the same exit status here
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8328: Move things in hir_ty into submodules r=flodiebold a=flodiebold
- all the types that will be replaced by Chalk go to `types`
- `TypeWalk` impls go to `walk`
- also fix signature of `Substitution::interned`
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
8325: Check if bitflags deps pulls its weight r=jonas-schievink a=matklad
Bitflags is generally a good dependency -- it's lightweight, well
maintained and embraced by the ecosystem.
I wonder, however, do we really need it? Doesn't feel like it adds much
to be honest.
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
8295: Add `convert_into_to_from` assist r=Veykril a=obmarg
This adds a "Convert Into to From" assist, useful since clippy has
recently started adding lints on every `Into`.
It covers converting the signature, and converting any `self`/`Self`
references within the body.
It does assume that every instance of `Into` can be converted to a
`From`, which I _think_ is the case now. Let me know if there's
something I'm not thinking of and I can try and make it smarter.
Closes#8196
![CleanShot 2021-04-02 at 13 39 54](https://user-images.githubusercontent.com/556490/113420108-9ce21c00-93c0-11eb-8c49-80b5fb189284.gif)
I'm extremely new to this codebase so please let me know if anything needs
changed.
Co-authored-by: Graeme Coupar <grambo@grambo.me.uk>
8327: Move `Ty` creation methods out of `Ty` (Chalk move preparation) r=flodiebold a=flodiebold
When we'll move to using `chalk_ir::Ty` (#8313), we won't be able to have our own inherent methods on `Ty` anymore, so we need to move the helpers elsewhere.
This adds a `TyBuilder` that allows easily constructing `Ty` and related types (`TraitRef`, `ProjectionTy`, `Substitution`). It also replaces `SubstsBuilder`. `TyBuilder` can construct different things based on its type parameter; e.g. if it has an `AdtId`, we're constructing an ADT type, but if it has a `TraitId`, we're constructing a `TraitRef`. The common thing for all of them is that we need to build a `Substitution`, so the API stays the same for all of them except at the beginning and end.
We also use `TyBuilder` to house various one-shot methods for constructing types, e.g. `TyBuilder::unit()`.
Co-authored-by: Florian Diebold <flodiebold@gmail.com>
Bitflags is generally a good dependency -- it's lightweight, well
maintained and embraced by the ecosystem.
I wonder, however, do we really need it? Doesn't feel like it adds much
to be honest.
8322: Access a body's block def maps via a method r=jonas-schievink a=jonas-schievink
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
8321: Use exhaustive matches in shrink_to_fit impls r=jonas-schievink a=jonas-schievink
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>