| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This reverts commit 008d5130b7dce96693cd9c39cd5e71d9dc73bd5b.
|
|
This reverts commit cc2686c1a9cf9a9e089f669d9d179812618008a7.
|
|
This reverts commit ecae5a8b33abfa7b084aa0bd29d47f5b98ea2527.
|
|
This reverts commit b82c5ceba8cfb595f3556593fb3eb9cd03b1fb5c.
|
|
This reverts commit b24723a5c74ab4881539bb97c7608c147f07c25e.
|
|
This reverts commit 536ac471c47f06fd53daa651424ea5a78189491c.
|
|
searching for the completion item to resolve"
This reverts commit fa46a9e2b605de60b11a29f5951e650c3c0f5089.
|
|
This reverts commit f0db79f31ada049bf490c8f27be7443f45460f09.
|
|
|
|
the completion item to resolve
|
|
|
|
|
|
|
|
|
|
Because damnit, it can crash r-a. Why do people make this stupid DFSes anyway (I get it, it's easier until it blows).
|
|
internal: add json `tracing` Layer for profiling startup
On `buck2/integrations/rust-project`, this results in the following being printed:
```json
{"name":"discover_command","elapsed_ms":18703}
{"name":"parallel_prime_caches","elapsed_ms":0}
{"name":"vfs_load","elapsed_ms":5895}
{"name":"vfs_load","elapsed_ms":547}
{"name":"parallel_prime_caches","elapsed_ms":23}
{"name":"parallel_prime_caches","elapsed_ms":84}
{"name":"parallel_prime_caches","elapsed_ms":5819}
```
|
|
|
|
internal: Filter out opaque tokens in some IDE feature macro descensions
|
|
|
|
fix: Fix bootstrap error message being incorrect
precedence ...
|
|
|
|
|
|
|
|
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.
|
|
them textually, instead reuse the results of HIR lowering
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.
https://github.com/rust-lang/rust-analyzer/blob/546339a7be357b3e95fc4b79a8816dce540d477b/crates/hir-ty/src/diagnostics/decl_check.rs#L60
https://github.com/rust-lang/rust-analyzer/blob/546339a7be357b3e95fc4b79a8816dce540d477b/crates/ide-diagnostics/src/handlers/incorrect_case.rs#L535
|
|
feat: Provide an config option to not set `cfg(test)`
Fixes #17957.
|
|
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
|
|
|
|
internal: allow overriding proc macro server in analysis-stats
Needed this argument in order to profile the proc macro expansion server (c.f., [this Zulip conversation](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/.60macro_rules!.60-based.20macros.20for.20derives.2Fattributes/near/473466794)). I also took the opportunity to change the phrasing for `--proc-macro-srv`.
Ran with `samply record ~/.cargo/bin/rust-analyzer analysis-stats --proc-macro-srv /Users/dbarsky/.cargo/bin/rust-analyzer-proc-macro-srv --parallel .` on rust-analyzer itself.
|
|
|
|
Up to a trait implemented by another package, linking to
$CARGO_HOME/registry/cache/index.crates.io-6f17d22bba15001f/
|
|
|
|
|
|
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
|
|
false to restart package-wide flycheck
|
|
|
|
|
|
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.
|
|
|
|
|
|
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.
|
