internal: remove `Default` from OpQueue
`@Wilfred` and I were talking about `OpQueue` and we identified one symptom of its (relative) weirdness is that `last_op_result` returns a `T::default()`; not `Option<&T>`, which means it's not possible to distinguish between "the `OpQueue` hasn't run yet" and "the OpQueue ran, but didn't produce a result". This branch fixes that.
fix: Fix resolution of label inside macro
When working on Something Else (TM) (I left a hint in the commits :P), I noticed to my surprise that labels inside macros are not resolved. This led to a discovery of *two* unrelated bugs, which are hereby fixed in two commits.
This fixes a bug where labels inside macros were not resolved, but more importantly this prepares us to a future where we have hygiene, and textual equivalence isn't enough to resolve identifiers.
internal: Send less data during `textDocument/completion` if possible
Similar to https://github.com/rust-lang/rust-analyzer/pull/15522, stops sending extra data during `textDocument/completion` if that data was set in the client completions resolve capabilities, and sends those only during `completionItem/resolve` requests.
Currently, rust-analyzer sends back all fields (including potentially huge docs) for every completion item which might get large.
Same as the other one, this PR aims to keep the changes minimal and does not remove extra computations for such fields — instead, it just filters them out before sending to the client.
The PR omits primitive, boolean and integer, types such as `deprecated`, `preselect`, `insertTextFormat`, `insertTextMode`, etc. AND `additionalTextEdits` — this one looks very dangerous to compute for each completion item (as the spec says we ought to if there's no corresponding resolve capabilities provided) due to the diff computations and the fact that this code had been in the resolution for some time.
It would be good to resolve this lazily too, please let me know if it's ok to do.
When tested with Zed which only defines `documentation` and `additionalTextEdits` in its client completion resolve capabilities, rust-analyzer starts to send almost 3 times less characters:
Request:
```json
{"jsonrpc":"2.0","id":104,"method":"textDocument/completion","params":{"textDocument":{"uri":"file:///Users/someonetoignore/work/rust-analyzer/crates/ide/src/inlay_hints.rs"},"position":{"line":90,"character":14},"context":{"triggerKind":1}}}
```
<img width="1338" alt="image" src="https://github.com/user-attachments/assets/104f19b5-7095-4fc1-b008-5d829623b2e2">
Before: 381944 characters
[before.json](https://github.com/user-attachments/files/17092385/before.json)
After: 140503 characters
[after.json](https://github.com/user-attachments/files/17092386/after.json)
After Zed's [patch](https://github.com/zed-industries/zed/pull/18212) to enable all resolving possible: 84452 characters
[after-after.json](https://github.com/user-attachments/files/17092755/after-after.json)
fix: Ambiguity with CamelCase diagnostic messages, align with rustc warnings
Fixed diagnostic messages so they say UpperCamelCase rather than CamelCase, as it is ambiguous.
Usually I'd call it PascalCase, but in the code base it is called UpperCamelCase so I left it with that naming choice.
`rustc` says `upper camel case` also when the case is wrong
```
warning: trait `testThing` should have an upper camel case name
--> src/main.rs:5:7
|
5 | trait testThing {
| ^^^^^^^^^ help: convert the identifier to upper camel case: `TestThing`
|
= note: `#[warn(non_camel_case_types)]` on by default
```
This is in line with the UPPER_SNAKE_CASE diagnostic messages.
546339a7be/crates/hir-ty/src/diagnostics/decl_check.rs (L60)546339a7be/crates/ide-diagnostics/src/handlers/incorrect_case.rs (L535)
This will mean users opting to not activate `cfg(test)` will lose IDE experience on them, which is quite unfortunate, but this is unavoidable if we want to avoid false positives on e.g. diagnostics. The real fix is to provide IDE experience even for cfg'ed out code, but this is out of scope for this PR.
Rename object_safety
First PR here (yay!), so I read some of the getting started docs. There are a couple references to `handlers.rs`, which as far as I can tell has been refactored into `handlers/*.rs`. I made some tweaks to that in one commit. There is one fixme about a function called `to_lsp_runnable`, which I can't find anywhere at all. I can update that if I get some more info there.
Otherwise I changed references to object safety, is object safe, etc., trying to match case/style as I went. There was one case I found where there's a trait from somewhere else called `is_object_safe`, which I found defined in my cargo registry. I didn't touch that for now, just marked it with a fixme
Include buildfiles in VFS
We subscribe to `textDocument/didSave` for `filesToWatch`, but the VFS doesn't contain those files. Before https://github.com/rust-lang/rust-analyzer/pull/18105, this would bring down the server. Now, it's only a benign error logged:
```
ERROR notification handler failed handler=textDocument/didSave error=file not found: /foo/bar/TARGETS
```
It's benign, because we will also receive a `workspace/didChangeWatchedFiles` for the file which will invalidate and load it.
Explicitly include the buildfiles in the VFS to prevent the handler from erroring.
Building before a debugging session was restarted
# Background
Resolves#17901. It adds support for rebuilding after debugging a test was restarted. This means the test doesn't have to be aborted and manually re-ran again.
# How this is tested
First, all the Visual Studio Code extensions are loaded into an Extension Host window. Then, a sample test like below was ran and restarted to see if it was correctly rebuild.
```rust
#[test]
fn test_x() {
assert_eq!("1.1.1", "1.1.0");
}
```
internal: Add `SyntaxFactory` to ease generating nodes with syntax mappings
Part of [#15710](https://github.com/rust-lang/rust-analyzer/issues/15710)
Instead of requiring passing a `&mut SyntaxEditor` to every make constructor to generate mappings, we instead wrap that logic in `SyntaxFactory`, and afterwards add all the mappings to the `SyntaxEditor`.
Includes an example of using `SyntaxEditor` & `SyntaxFactory` in the `extract_variable` assist.
minor: Stricter requirements for package wide flycheck
Require the existence of a target and `check_workspace` to be false to restart package-wide flycheck. Fixes#18194 , #18104
fix: Don't report a startup error when a discover command is configured
Previously, r-a would show an error if both fetch_workspaces_queue and discover_workspace_queue were empty. We're in this state at startup, so users would see an error if they'd configured
discover_workspace_config.
Instead, allow the fetch_workspaces_queue to have zero items if discover_workspace_config is set.
Whilst we're here, prefer "failed to fetch" over "failed to discover", so the error message better reflects what this function is doing.
Previously, r-a would show an error if both fetch_workspaces_queue and
discover_workspace_queue were empty. We're in this state at startup,
so users would see an error if they'd configured
discover_workspace_config.
Instead, allow the fetch_workspaces_queue to have zero items if
discover_workspace_config is set.
Whilst we're here, prefer "failed to fetch" over "failed to discover",
so the error message better reflects what this function is doing.
Require rust 1.81
rust-analyzer doesn't build on 1.80 because we use `#[expect(lint)]`:
```
error[E0658]: the `#[expect]` attribute is an experimental feature
--> crates/hir-expand/src/prettify_macro_expansion_.rs:11:1
|
11 | #[expect(deprecated)]
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #54503 <https://github.com/rust-lang/rust/issues/54503> for more information
```
feat: Index workspace symbols at startup rather than on the first symbol search.
This will eliminate potential many-second delays when performing the first search, at the price of making cache priming (“Indexing N/M” in the VS Code status bar) take a little longer in total. Hopefully this additional time is insignificant because a typical session will involve at least one symbol search.
Further improvement would be to do this as a separate parallel task (which will be beneficial if the workspace contains a small number of large crates), but that would require significant additional refactoring of the progress-reporting mechanism to understand multiple tasks per crate. Happy to tackle that in this PR if desired, but I thought I'd propose the minimal change first.
internal: add tracing to project discovery and VFS loading
With `"env RA_PROFILE=vfs_load|parallel_prime_caches|discover_command>500`, this results in the following output:
```
21888ms discover_command
11627ms vfs_load @ total = 701
1503ms vfs_load @ total = 701
30211ms parallel_prime_caches
```
As a followup, I'd like to make hprof emit the information above as JSON.
fix: Pass all-targets for build scripts in more cli commands
Without this, build scripts don't run for tests and as such any proc-macros in dev-deps fail to resolve
Add `optimize_for_size` variants for stable and unstable sort as well as select_nth_unstable
- Stable sort uses a simple merge-sort that re-uses the existing - rather gnarly - merge function.
- Unstable sort jumps directly to the branchless heapsort fallback.
- select_nth_unstable jumps directly to the median_of_medians fallback, which is augmented with a custom tiny smallsort and partition impl.
Some code is duplicated but de-duplication would bring it's own problems. For example `swap_if_less` is critical for performance, if the sorting networks don't inline it perf drops drastically, however `#[inline(always)]` is also a poor fit, if the provided comparison function is huge, it gives the compiler an out to only instantiate `swap_if_less` once and call it. Another aspect that would suffer when making `swap_if_less` pub, is having to cfg out dozens of functions in in smallsort module.
Part of https://github.com/rust-lang/rust/issues/125612
r? `@Kobzol`
