assist: ensure `replace_qualified_name_with_use` applies to the first path segment
This change helps a bit with the discoverability of `replace_qualified_name_with_use`. Specifically, it ensures that a cursor on the first path segment (e.g., `$0std::fmt::Debug`, where `$0` is the cursor) would result in an import along the lines of `use std::fmt;` and `fmt::Debug;` at the usage sites.
Skip checks for cast to dyn traits
It seems that chalk fails to solve some obvious goals when there are some recursiveness in trait environments.
And it doesn't support trait upcasting yet. rust-lang/chalk#796
This PR just skips for casting into types containing `dyn Trait` to prevent false positive diagnostics like #18047 and #18083
This is a small change, but it was the cause of 90% of the errors in `rust-analyzer diagnostics .` 🫢
With this change and #18085 together, all remaining errors are type errors.
This may mean we can enable more errors, but this is out of scope for this PR.
internal: Add preliminary `SyntaxEditor` functionality
Related to #15710
Implements a `SyntaxEditor` interface to abstract over the details of modifying syntax trees, to both simplify creating new code fixes and code actions, as well as start on the path of getting rid of mutable syntax nodes.
`SyntaxEditor` relies on `SyntaxMappingBuilder`s to feed in the correct information to map AST nodes created by `make` constructors, as `make` constructors do not guarantee that node identity is preserved. This is to paper over the fact that `make` constructors simply re-parse text input instead of building AST nodes from the ground up and re-using the provided syntax nodes.
`SyntaxAnnotation`s are used to find where syntax elements have ended up after edits are applied. This is primarily useful for the `add_{placeholder,tabstop}` set of methods on `SourceChangeBuilder`, as that currently relies on the nodes provided being in the final syntax tree.
Eventually, the goal should be to move this into the `rowan` crate when we move away from mutable syntax nodes, but for now it'll stay in the `syntax` crate.
---
Closes#14921 as `SyntaxEditor` ensures that all replace changes are disjoint
Closes#9649 by implementing `SyntaxAnnotation`s
feat: better name suggestions for fn
fix#17631.
Better name suggestions for fn-calls / method-calls in the form of `from()`, `from_xxx()`, `into()`, etc.
`linkedProjects` is owned by the user's configuration, so when users
update this setting, `linkedProjects` is reset. This is problematic when
`linkedProjects` also contains projects discovered with `discoverCommand`.
The buggy behaviour occurred when:
(1) The user configures `discoverCommand` and loads a Rust project.
(2) The user changes any setting in VS Code, so rust-analyzer receives
`workspace/didChangeConfiguration`.
(3) `handle_did_change_configuration` ultimately calls
`Client::apply_change_with_sink()`, which updates `config.user_config`
and discards any items we added in `linkedProjects`.
Instead, separate out `discovered_projects_from_filesystem` and
`discovered_projects_from_command` from user configuration, so user
settings cannot affect any type of discovered project.
This fixes the subtle issue mentioned here:
https://github.com/rust-lang/rust-analyzer/pull/17246#issuecomment-2185259122
feat: Suggest name in completion for let_stmt and fn_param
fix#17780
1. Refactor: move `ide_assist::utils::suggest_name` to `ide-db::syntax_helpers::suggest_name` for reuse.
2. When completing `IdentPat`, detecte if the current node is a `let_stmt` or `fn_param`, and suggesting a new name based on the context.
fix: use Result type aliases in "Wrap return type in Result" assist
This commit makes the "Wrap return type in Result" assist prefer type aliases of standard library type when the are in scope, use at least one generic parameter, and have the name `Result`.
The last restriction was made in an attempt to avoid false assumptions about which type the user is referring to, but that might be overly strict. We could also do something like this, in order of priority:
* Use the alias named "Result".
* Use any alias if only a single one is in scope, otherwise:
* Use the standard library type.
This is easy to add if others feel differently that is appropriate, just let me know.
Fixes#17796
