Implement completion for the callable fields.
Fixes#14656
PR is opened with basic changes. It could be improved by having a new `SymbolKind` for the callable fields and implementing a separate render function similar to the `render_method` for the new `SymbolKind`.
It could also be done without any changes to the `SymbolKind` of course, have the new function called based on the type of field.
I prefer the former method.
Please give any thoughts or changes you think is appropriate for this method. I could start working on that in this same PR.
chore: remove unused `PhantomData`
This PR removes an unused `PhantomData` in `FileItemTreeId`.
*Note:* I am not sure how this should be implemented, maybe as a type instead of a wrapper struct? I'd be happy to do so if needed 👍
Improve error handling for top-level `let` statements
This commit addresses the issue of excessive and unrelated errors generated by top-level `let` statements. Now, only a single error is produced, indicating that `let` statements are invalid at the top level.
---
Fixes https://github.com/rust-lang/rust-analyzer/issues/14963.
While I'm not really sure if handling a particular case in a special manner is appropriate, it would be good to suppress the excessive number of annoying and unrelated errors.
This commit addresses the issue of excessive and unrelated errors
generated by top-level `let` statements. Now, only a single error is
produced, indicating that `let` statements are invalid at the top level.
internal: simplify the removal of dulicate workspaces.
### Summary:
Refactoring the duplicate removal process for `workspaces` in `fetch_workspaces`.
### Changes Made:
Replaced `[].iter().enumerate().skip(...).filter_map(...)` with a more concise `[i+1..].positions(...)` provided by `itertools`, which enhances clarity without changing functionality
### Impact:
This change aims to enhance the duplicate removal process for `workspaces`. This change has been tested on my machine.
Please review and provide feedback. Thanks!
fix: add fallback for completion label details
This PR adds a fallback to a previous implementation in a case when the label detail field isn't supported by LSP client and the support isn't reported by the LSP initialize request. In this case additional info about trait and aliases would be merged into the label field as it was before the #15956 PR.
editor/code: add option to suppress error notifications
Fixes https://github.com/rust-lang/rust-analyzer/issues/14193
- Added the `rust-analyzer.showRequestFailedErrorNotification` configuration option, which defaults to `true`
- If `rust-analyzer.showRequestFailedErrorNotification` is set to `true`, the current behavior is preserved.
- If `rust-analyzer.showRequestFailedErrorNotification` is set to `false`, no error toasts will be displayed for any of the failed requests caused by panics in r-a. This _only_ applies to events that are triggered "implicitly", such as `textDocument/hover`.
To test this, you can manually introduce a panic in one of the language server LSP handlers for non-command events. I added an explicit `panic!()` in the `textDocument/hover` event handler:
#### `rust-analyzer.showRequestFailedErrorNotification` set to `true` (default)
[2023-11-07 17-17-48.webm](https://github.com/rust-lang/rust-analyzer/assets/1665677/d0408ab8-79d1-42cf-a4e7-94e99d9783ec)
#### `rust-analyzer.showRequestFailedErrorNotification` set to `false`
[2023-11-07 17-16-49.webm](https://github.com/rust-lang/rust-analyzer/assets/1665677/0496d8d0-fb53-4bc6-a279-1a47f412dbdb)
fix: Dedup duplicate crates with differing origins in CrateGraph construction
Partially fixes#15656 . Until now the condition for deduplication in crate graphs were the strict equality of two crates. One problem that arises from this is that in certain conditions when we see the same crate having different `CrateOrigin`s the first occurrence would be kept. This approach however results in some unwanted results such as making renaming forbidden as this has been recently only made available for local crates. The given example in #15656 can still not be resolved with this PR as that involves taking inconsistencies between dependencies into consideration. This will be addressed in a future PR.
