Trigger VSCode to rename after extract variable assist is applied
When the user applies the "Extract Variable" assist, the cursor is
positioned at the newly inserted variable. This commit adds a command
to the assist that triggers the rename action in VSCode. This way, the
user can quickly rename the variable after applying the assist.
Fixes part of: #17579https://github.com/user-attachments/assets/4cf38740-ab22-4b94-b0f1-eddd51c26c29
I haven't yet looked at the module or function extraction assists yet.
When the user applies the "Extract Variable" assist, the cursor is
positioned at the newly inserted variable. This commit adds a command
to the assist that triggers the rename action in VSCode. This way, the
user can quickly rename the variable after applying the assist.
Fixes part of: #17579
Add `f16` and `f128` support
Adds `f16` and `f128` support, using the `rustc_apfloat` library (also used by `rustc`) for parsing/arithmetic/displaying since the types aren't stable yet so can't be used by rust-analyzer itself.
Issue: #17451
feat: add inlay hints for generic parameters
fixes#11091
By default, only hints for const generic parameters are shown, and this can be configured through `rust-analyzer.inlayHints.genericParameterHints.enable`.
Probably needs more testing.
Filter builtin macro expansion
This PR adds a filter on the types of built in macros that are allowed to be expanded.
Currently, This list of allowed macros contains, `stringify, cfg, core_panic, std_panic, concat, concat_bytes, include, include_str, include_bytes, env` and `option_env`.
Fixes#14177
fix: handle character boundaries for wide chars in extend_selection
fix#17420.
When calling 'extend_selection' within a string, r-a attempts to locate the current word at the cursor. This is done by finding the first char before the cursor which is not a letter, digit, or underscore.
The position of this character is referred to as `start_idx`, and the word is considered to start from `start_idx + 1`. However, for wide characters, `start_idx + 1` is not character boundaries, which leading to panic. We should use `ceil_char_boundary` to ensure that the idx is always on character boundaries.
feat: TOML based config for rust-analyzer
> Important
>
> We don't promise _**any**_ stability with this feature yet, any configs exposed may be removed again, the grouping may change etc.
# TOML Based Config for RA
This PR ( addresses #13529 and this is a follow-up PR on #16639 ) makes rust-analyzer configurable by configuration files called `rust-analyzer.toml`. Files **must** be named `rust-analyzer.toml`. There is not a strict rule regarding where the files should be placed, but it is recommended to put them near a file that triggers server to start (i.e., `Cargo.{toml,lock}`, `rust-project.json`).
## Configuration Types
Previous configuration keys are now split into three different classes.
1. Client keys: These keys only make sense when set by the client (e.g., by setting them in `settings.json` in VSCode). They are but a small portion of this list. One such example is `rust_analyzer.files_watcher`, based on which either the client or the server will be responsible for watching for changes made to project files.
2. Global keys: These keys apply to the entire workspace and can only be set on the very top layers of the hierarchy. The next section gives instructions on which layers these are.
3. Local keys: Keys that can be changed for each crate if desired.
### How Am I Supposed To Know If A Config Is Gl/Loc/Cl ?
#17101
## Configuration Hierarchy
There are 5 levels in the configuration hierarchy. When a key is searched for, it is searched in a bottom-up depth-first fashion.
### Default Configuration
**Scope**: Global, Local, and Client
This is a hard-coded set of configurations. When a configuration key could not be found, then its default value applies.
### User configuration
**Scope**: Global, Local
If you want your configurations to apply to **every** project you have, you can do so by setting them in your `$CONFIG_DIR/rust-analyzer/rust-analyzer.toml` file, where `$CONFIG_DIR` is :
| Platform | Value | Example |
| ------- | ------------------------------------- | ---------------------------------------- |
| Linux | `$XDG_CONFIG_HOME` or `$HOME`/.config | /home/alice/.config |
| macOS | `$HOME`/Library/Application Support | /Users/Alice/Library/Application Support |
| Windows | `{FOLDERID_RoamingAppData}` | C:\Users\Alice\AppData\Roaming |
### Client configuration
**Scope**: Global, Local, and Client
Previously, the only way to configure rust-analyzer was to configure it from the settings of the Client you are using. This level corresponds to that.
> With this PR, you don't need to port anything to benefit from new features. You can continue to use your old settings as they are.
### Workspace Root Configuration
**Scope**: Global, Local
Rust-analyzer already used the path of the workspace you opened in your Client. We used this information to create a configuration file that won't affect your other projects and define global level configurations at the same time.
### Local Configuration
**Scope**: Local
You can also configure rust-analyzer on a crate level. Although it is not an error to define global ( or client ) level keys in such files, they won't be taken into consideration by the server. Defined local keys will affect the crate in which they are defined and crate's descendants. Internally, a Rust project is split into what we call `SourceRoot`s. This, although with exceptions, is equal to splitting a project into crates.
> You may choose to have more than one `rust-analyzer.toml` files within a `SourceRoot`, but among them, the one closer to the project root will be
fix: do not resolve prelude within block modules
fix#17338 (continuing from #17251).
In #17251, we injected preludes into non-top-level modules, which leading to r-a to directly resolve names in preludes in block modules. This PR fix it by checking whether the module is a pseudo-module introduced by blocks. (similar to what we do for extern preludes)
