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
I'm extremely new to this codebase so please let me know if anything needs
changed.
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()`.
8318: Use shrink_to_fit to reduce DefMap sizes r=jonas-schievink a=jonas-schievink
Especially `block_def_map` can overallocate when there's not a lot of items in the `DefMap`. This saves around 10 MB during analysis-stats. Not too much, but a cheap win.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
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 to the correct types.
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.
8298: Stop using an upgradeable read lock in interning r=jonas-schievink a=jonas-schievink
Only one upgradeable read lock can be handed out at the same time, and
we never acquire a non-upgradeable read lock, so this has no benefit
over just using a write lock in the first place.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Jonas Schievink [Fri, 2 Apr 2021 18:46:37 +0000 (20:46 +0200)]
Stop using an upgradeable read lock in interning
Only one upgradeable read lock can be handed out at the same time, and
we never acquire a non-upgradeable read lock, so this has no benefit
over just using a write lock in the first place.
8285: Don't recheck obligations if we have learned nothing new r=matklad a=flodiebold
This is just the most trivial check: If no inference variables have been updated, and there are no new obligations, we can just skip trying to solve them again. We could be smarter about it, but this already helps quite a bit, and I don't want to touch this too much before we replace the inference table by Chalk's.
* Emitting hint-level diagnostics at *all* macro invocation sites that caused the diagnostic
* Previously we emitted a copy of the diagnostic (not at hint level) at the last macro invocation site only
* Emitting the original diagnostic inside the macro, if it was caused by a macro
* Always including related information pointing to the invocation site or the macro, respectively (the old code contained a bug that would sometimes omit it)
Prior we were only resolving paths until the first type was found, then discarding the result if the path wasn't fully consumed. That of course causes associated types to not resolve. Fixes #5003
Don't recheck obligations if we have learned nothing new
This is just the most trivial check: If no inference variables have been
updated, and there are no new obligations, we can just skip trying to
solve them again. We could be smarter about it, but this already helps
quite a bit, and I don't want to touch this too much before we replace
the inference table by Chalk's.
8274: Adding a few more gifs and screenshots for features in manual r=Veykril a=MozarellaMan
Related #8267,#6539. Gifs are [here](https://github.com/rust-analyzer/rust-analyzer/issues/6539#issuecomment-809574840)
Finishing up the last PR, for the last two features that didn't have a visual example.
For syntax highlighting, I wasn't able to find a theme that displayed the difference between an enum and struct, but I only tried a few apart from the default so there could be one out there!
e.g., with the default light theme, `Ord` and `Ordering` in `use std::cmp::{Ord, Ordering}` had the same highlight colour. So I just went with displaying `mut` items being underlined.
bors[bot] [Wed, 31 Mar 2021 10:01:56 +0000 (10:01 +0000)]
Merge #8267
8267: Adding gifs and screenshots for features in manual r=matklad a=MozarellaMan
For #6539
This includes most of gif or screenshot examples of most items in the "Features" header. With the exceptions of:
- **On Typing Assists** - couldn't get it to work for a demo, I'm probably missing something?
- **Structural search and replace** - looked to be already a visual example of the feature
- **Workspace symbol** - wasn't sure how best to show this, all of the examples maybe? Also wasn't sure of the best code example to show it off
- **Semantic Syntax Highlighting** - seemed obvious enough to not need a screenshot, but I could easily add this
All the gifs/pngs are hosted in this [comment](https://github.com/rust-analyzer/rust-analyzer/issues/6539#issuecomment-809574840). Please let me know if any of them aren't suitable (and why) and I'll improve it! Or if you don't like the theme/font
projects / rust.git / log