6220: implement binary operator overloading type inference r=flodiebold a=ruabmbua
Extend type inference of *binary operator expression*, by adding support for operator overloads.
Before this merge request, the type inference of binary expressions could only resolve operations done on built-in primitive types. This merge requests adds a code path, which is executed in case the built-in inference could not get any results. It resolves the proper operator overload trait in *core::ops* via lang items, and then resolves the associated *Output* type.
```rust
struct V2([f32; 2]);
#[lang = "add"]
pub trait Add<Rhs = Self> {
/// The resulting type after applying the `+` operator.
type Output;
/// Performs the `+` operation.
#[must_use]
fn add(self, rhs: Rhs) -> Self::Output;
}
impl Add<V2> for V2 {
type Output = V2;
fn add(self, rhs: V2) -> V2 {
let x = self.0[0] + rhs.0[0];
let y = self.0[1] + rhs.0[1];
V2([x, y])
}
}
fn test() {
let va = V2([0.0, 1.0]);
let vb = V2([0.0, 1.0]);
let r = va + vb; // This infers to V2 now
}
```
There is a problem with operator overloads, which do not explicitly set the *Rhs* type parameter in the respective impl block.
**Example:**
```rust
impl Add for V2 {
type Output = V2;
fn add(self, rhs: V2) -> V2 {
let x = self.0[0] + rhs.0[0];
let y = self.0[1] + rhs.0[1];
V2([x, y])
}
}
```
In this case, the trait solver does not realize, that the *Rhs* type parameter is actually self in the context of the impl block. This stops type inference in its tracks, and it can not resolve the associated *Output* type.
I guess we can still merge this back, because it increases the amount of resolved types, and does not regress anything (in the tests).
Somewhat blocked by https://github.com/rust-analyzer/rust-analyzer/issues/5685
Resolves https://github.com/rust-analyzer/rust-analyzer/issues/5544
Co-authored-by: Roland Ruckerbauer <roland.rucky@gmail.com>
6234: Fix hover over field pattern shorthand r=matklad a=Vlad-Shcherbina
Instead of the information about the field, it now shows the information
about the local.
Fixes#6146
Co-authored-by: Vlad Shcherbina <vlad.shcherbina@gmail.com>
6231: Factor macro_rules and format-string highlighting out into submodules r=Veykril a=Veykril
This moves `format`-like macro string highlighting and macro_rules highlight skipping out of the main module.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6207: Extract ImportAssets out of auto_import r=matklad a=Veykril
See https://github.com/rust-analyzer/rust-analyzer/pull/6172#issuecomment-707182140
I couldn't fully pull out `AssistContext` as `find_node_at_offset_with_descend`: 81fa00c5b5/crates/assists/src/assist_context.rs (L90-L92) requires the `SourceFile` which is private in it and I don't think making it public just for this is the right call?
6224: ⬆️ salsa r=matklad a=matklad
bors r+
🤖
6226: Add reminder to update lsp-extensions.md r=matklad a=matklad
bors r+
🤖
6227: Reduce bors timeout r=matklad a=matklad
bors r+
🤖
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Co-authored-by: Aleksey Kladov <aleksey.kladov@gmail.com>
6130: Items case quick fix (snake_case / UPPER_SNAKE_CASE / CamelCase) r=matklad a=popzxc
Resolves#4598.
After a third try, it finally works. Boy, it appeared tougher than it seemed.
Initially I thought like "Ha, `rustc` already tells us where idents are named incorrectly. It shouldn't be that hard, should it?".
Well, the problems with the information provided by `rustc` appeared shortly:
- `rustc` warnings are `flycheck` warnings, which are slightly aside from our diagnostics with fixes.
When we map flycheck diagnostic to LSP, we can convert it into a fix, but only if it's marked as `Applicability::MachineApplicable`.
Name case fix is marked `Applicability::MaybeIncorrect`, and for a reason: it only suggest to rename symbol under cursor, without tracking any references.
- Warning spawned by `rustc` are identified by string labels rather than enum. It means that if one day the diagnostic will be renamed in `rustc`, `rust-analyzer` code will still compile, but won't find the required diagnostic by name anymore. If by chance this will happen when some unlucky guy will decide to create their first pull request, they'll be confused by suddenly failing tests (likely) not related to their changes.
- Even if we'll try to build fixes atop of `rustc` warnings, we'll have to do it in the `rust_analyzer::diagnostics::to_proto` module, which is far less
convenient for that matter than `ide` crate.
That's why I decided that it's worth a separate `rust-analyzer` diagnostic, which will implement `DiagnosticWithFix` trait.
After that, I discovered that currently `hir_ty::diagnostics` only check `DefWithBody` types, like function bodies. I had to add support for diagnostics
which look at any `ModuleDef`.
And of course, since I'd added a lot of new functionality, it required extensive testing.
That explains why the diff is so big for a (looking) relatively small feature.
I hope that this PR doesn't only add a small feature, but also creates a base for building another features.
## Example:
P.S. My eyes were bleeding when I had to write the code for the example...
6135: when generating new function, focus on return type instead of body r=matklad a=bnjjj
I made a little change when we use the assist to generate a new function, instead of focusing on the function body, it will focus on return type
Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
Co-authored-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
6205: Fix iterator hint shortening heuristic r=SomeoneToIgnore a=Veykril
Turns out I made a mistake with the heuristic check which is always true, so all iterators exposed from `core` were shortened, including things like ranges. 😅
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6153: Improve prime_caches and display its progress r=matklad a=jonas-schievink
It now computes the `CrateDefMap` of all crates, which is generally a reasonable approximation for "IDE features ready". There is still some delay after this finishes, I suspect mostly due to impl collection, which takes a while, but this should be an improvement already.
For more accurate progress reports, this topologically sorts all crates before starting this operation. ~~Because that is also the ordering in which parallelization makes sense (which was previously attempted in https://github.com/rust-analyzer/rust-analyzer/pull/3529), I decided to throw that into the mix as well. It still doesn't provide *that* much of a performance boost, but it does scale beyond the current single-core architecture, and adding it was very easy.~~
~~Unfortunately, as written, this will not tell the user which crate is actually causing slowdowns, since the displayed crate is the last one that was *started*, not the one we are currently *blocked* on, but that seems fairly difficult to implement unless I'm missing something.~~
(I have removed rayon for now since it does not work correctly with cancellation.)
Co-authored-by: Jonas Schievink <jonas.schievink@ferrous-systems.com>
6198: Skip macro matcher fragment name semantic highlighting r=matklad a=Veykril
Implements a small state-machine for macro_rules! highlighting to separate out the matcher part of its rules. This skips semantically highlighting names of metavariables in the matcher and expander. This might even allow for more fun macro highlighting things in the future.
Fixes#4380.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
6199: Fix `mut self` not emitting mutable binding on `self` use r=matklad a=Veykril
Prior to this, when `self` in a function is taken by value and bound mutably, its use inside of the method body won't be marked `mutably`.
Fixes#5461
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
