6274: Check cargoExtraArgs for undefined before using r=matklad a=feileacan
Fixes#6273
Co-authored-by: feileacan <54381366+feileacan@users.noreply.github.com>
This errro specifically:
Updating crates.io index
error: failed to select a version for the requirement `ra_ap_stdx = "^0.0.0"`
candidate versions found which didn't match: 0.0.20
location searched: /home/runner/work/rust-analyzer/rust-analyzer/crates/stdx
required by package `ra_ap_completion v0.0.20 (/home/runner/work/rust-analyzer/rust-analyzer/crates/completion)`
error: unable to update Cargo.lock
Error: Process completed with exit code 1.
6276: Extract call_info and completion into separate crates r=matklad a=popzxc
As it was discussed in [zulip](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Fwg-rls-2.2E0/topic/Completion.20refactoring), we need to move `completions` into a separate crate.
Unfortunately, the dependency on `call_info::ActiveParameter` doesn't look easy to get rid of, and it seems to be a topic for a separate PR, thus I also extracted `call_info` into a separate crate (on which both `ide` and `completion` crates depend).
Additionally, a few `FIXME`s in doc-comments were resolved in order to make `tidy` happy.
Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
6275: Textmate grammar: prevent unwanted interpolation scopes r=matklad a=dustypomerleau
Fixes the issues noted by @matklad after merging #6248.
1. prevent accidental interpolation scopes when `{` is used in a string
1. prevent interpolations from extending beyond the end of a string
Co-authored-by: Dusty Pomerleau <dustypomerleau@users.noreply.github.com>
6262: Do not spawn redundant hints r=SomeoneToIgnore a=popzxc
Closes#5206
This is a second part of the fix (first was #5997).
This PR adds a new method to the `CompletionContext`: `no_completion_required`. If this method returns `true`, it essentially means that user is unlikely to expect any hints from the IDE at this cursor position.
Currently, checks for the following cases were added:
- Previous item is `fn`: user creates a new function, names of existing functions won't be helpful. Exception for this case is `impl Foo for Bar` -- we must suggest trait function names.
- User entered `for _ i<|>`: it's obviously going to be `in` keyword, any hints here will be confusing.
More checks may be added there later, but currently I've only figured two cases.
Co-authored-by: Igor Aleksanov <popzxc@yandex.ru>
6246: Follow symlinks when walking project trees r=lnicola a=dfoxfranke
Fixes#3691.
~~WIP pending further testing~~:
- [X] Verify that symlinked files get indexed.
- [x] Verify that files in symlinked directories get indexed.
- [x] Verify that inotify events are properly received and handled when the target of a symlink resides outside the project tree.
Co-authored-by: Daniel Fox Franke <dfoxfranke@gmail.com>
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>
