internal: Switch to `expected.assert_eq` for `ide` tests
This PR switches from `assert_debug_eq` to `assert_eq` and only compares parts of the result and not the whole. The aim is to only compare parts which are relevant to the test and also make it more readable.
Part of #14268.
## Questions
- [x] Can I use `Vec`? If not, what is the alternative?
I assume I cannot because of: c3a00b5468/docs/dev/architecture.md (L413)
- [x] Should I group it by file, as proposed by Lukas?
```
file_id 1:
source_file_edits:
- Indel { insert: "foo2", delete: 4..7 }
file_id 2:
file_system_edits:
MoveFile AnchoredPathBuf { anchor: FileId(2), path: "foo2.rs", }
```
- [x] Is it okay to ignore `CreateFile` events? They do not have a FileId, which would be problematic, but they do not occur in the existing tests, so I marked them as `unreachable!()` so far.
feat: resolve inherent and implemented associated items in docs
This partially fixes#9694.
Supported:
- Trait methods and constants.
* Due to resolution differences pointed out during the review of the PR, trait associated types are _not_ supported.
- Inherent methods, constants and associated types.
* Inherent associated types are a [nightly feature](https://github.com/rust-lang/rust/issues/8995), and are supported with no additional work in this PR.
Screenshot of VS Code running with the change:
<img width="513" alt="image" src="https://github.com/rust-lang/rust-analyzer/assets/7189784/c37ed8b7-b572-4684-8e81-2a817b0027c4">
You can see that the items are resolved (excl. trait associated types) since they are semantically highlighted in the doc comment.
fix: try obligation of `IndexMut` when infer
Closes#15842.
This issue arises because `K` is ambiguous if only inferred from `Index` trait, but is unique if inferred from `IndexMut`, but r-a doesn't use this info.
Updated instructions for installing rust-analyzer under Gentoo.
No need to install the guru overlay to install rust-analyzer. This is now installed based on use flag settings for dev-lang/rust and dev-lang/rust-bin. This pull request changes the instructions in the user manual.
Note: rust-analyzer is not available in the guru repository, so the old instructions no longer work.
SymbolInformation::kind is finer-grained than the SCIP symbol suffix.
This also fixes a bug where all type aliases where treated like type
parameters.
```
trait SomeTrait {
type AssociatedType; // ← this is SomeTrait#[AssociatedType]
}
type MyTypeAlias = u8; // ← this used to be [MyTypeAlias]
// and now is MyTypeAlias#
```
To build the SymbolInformation::signature_documentation we need access
to the “label” when building the TokenStaticData, preferably without
any markdown markup.
Therefore this refactors ide::hover::render::definition and its helper
functions to give easier access to the label alone.
For local variables, this gets the moniker from the enclosing
definition and stores it into the TokenStaticData.
Then it builds the scip symbol for that moniker when building the
SymbolInformation.
This is meant to implement SymbolInformation::enclosing_symbol, so we
can build the enclosing symbol from the enclosing moniker without
having the full enclosing token's TokenStaticData.
fix: pick up new names when the name conflicts in 'introduce_named_generic'
Improve generation of names for generic parameters in `introduce_named_generics`.
fix#15731.
### Changes
- Modified `for_generic_parameter` function in `suggest_name.rs` to handle conflicts with existing generic parameters and generate unique names accordingly.
- Update `introduce_named_generic` function and pass existing params to `for_generic_parameter`, enabling the detection and handling of name collisions.
fix(completion): make the expected type a tad smarter with `Fn`s
This commit changes how the expected type is calculated when
working with Fn pointers, making the parenthesis stop vanishing
when completing the function name.
I've been bugged by the behavior of parenthesis completion for
a long while now. R-a assumes that the `LetStmt` type is the same
as the function type I've just written. Worse is that all parenthesis
vanish, even from functions that have completely different signatures.
It will now verify if the signature is the same.
While working on this, I noticed that record fields behave the same,
so I also made it prioritize the field type instead of the current
expression when possible, but I'm unsure if this is OK, so input is
appreciated.
ImplTraits as return types will still behave weirdly because lowering
is disallowed at the time it resolves the function types.
* Extracted the function `for_unique_generic_name` that handling generics with identical names for reusability.
* Renamed `for_generic_params` to `for_impl_trait_as_generic` for clarity
* Added documentations for `for_impl_trait_as_generic` and `for_unique_generic_name`
