| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
fix: Don't panic lsp writer thread on dropped receiver
Should reduce the noise a bit (https://github.com/rust-lang/rust-analyzer/issues/18055). This removes the panic (and a follow up panic) when the server incorrectly shuts down, turning it into a proper late exit error.
|
|
|
|
fix: Catch panics from diagnostics computation
|
|
|
|
fix: Updating settings should not clobber discovered projects
`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
|
|
`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
|
|
fix: Couple asm! parsing and lowering fixes
|
|
|
|
|
|
feat: IDE support for `asm!` expressions
Fixes https://github.com/rust-lang/rust-analyzer/issues/10461, Fixes https://github.com/rust-lang/rust-analyzer/issues/6031 Progresses https://github.com/rust-lang/rust-analyzer/issues/11621
Notably this only works for asm expressions not items yet. Most IDE features work, mainly completions need extra logic still.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fix: Fix lowering of for loops dropping the loop block
|
|
|
|
internal: Add edition dependent keyword highlighting tests
|
|
|
|
Bump `smol_str`
|
|
|
|
feat: Implement cast typecheck and diagnostics
Fixes #17897 and fixes #16564
Mainly adopted from https://github.com/rust-lang/rust/blob/100fde5246bf56f22fb5cc85374dd841296fce0e/compiler/rustc_hir_typeck/src/cast.rs
|
|
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.
|
|
|
|
|
|
|
|
|
|
minor: fix two nits
|
|
|
|
|
|
fix: lifetime hint panic in non generic defs
|
|
|
|
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
|
|
internal: Adjust completions scoring
|
|
|
|
|
|
minor: remove repetitive words
|
|
Signed-off-by: cuishuang <imcusg@gmail.com>
|
|
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.
|
|
internal: Lay basic ground work for standalone mbe tests
Most of our mbe hir-def tests don't actually do anything name res relevant, we can (and should) move those down the stack into `mbe/hir-expand`.
|
|
|
|
Add explicit enum discriminant assist
Add assist for adding explicit discriminants to all variants of an enum.
Closes #17798.
|
|
|
|
feat(ide-completion): extra sugar auto-completion `async fn ...` in `impl trait` for `async fn in trait` that's defined in desugar form
Solves #17719.
---
Preview
<img width="670" alt="image" src="https://github.com/user-attachments/assets/64ccef84-4062-4702-8760-89220585f422">
<img width="540" alt="image" src="https://github.com/user-attachments/assets/d22637f9-d531-43b2-a9f1-cd40a002903a">
<img width="631" alt="image" src="https://github.com/user-attachments/assets/21cd2142-bb8e-4493-9ac7-e6a9e7076904">
|
|
|
