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`
llvm: replace some deprecated functions
`LLVMMDStringInContext` and `LLVMMDNodeInContext` are deprecated, replace them with `LLVMMDStringInContext2` and `LLVMMDNodeInContext2`.
Also replace `Value` with `Metadata` in some function signatures for better consistency.
fix: Fix a bug in span map merge, and add explanations of how span maps are stored
Because it took me hours to figure out that contrary to common sense, the offset stored is the *end* of the node, and we search by the *start*. Which is why we need a convoluted `partition_point()` instead of a simple `binary_search()`. And this was not documented at all. Which made me make mistakes with my implementation of `SpanMap::merge()`.
The other bug fixed about span map merging is correctly keeping track of the current offset in presence of multiple sibling macro invocations. Unrelated, but because of the previous issue it took me hours to debug, so I figured out I'll put them together for posterity.
Fixes#18163.
fix: Fix name resolution when an import is resolved to some namespace and then later in the algorithm another namespace is added
The import is flagged as "indeterminate", and previously it was re-resolved, but only at the end of name resolution, when it's already too late for anything that depends on it.
This issue was tried to fix in https://github.com/rust-lang/rust-analyzer/pull/2466, but it was not fixed fully.
That PR is also why IDE features did work: the import at the end was resolved correctly, so IDE features that re-resolved the macro path resolved it correctly.
I was concerned about the performance of this, but this doesn't seem to regress `analysis-stats .`, so I guess it's fine to land this. I have no idea about the incremental perf however and I don't know how to measure that, although when typing in `zbus` (including creating a new function, which should recompute the def map) completion was fast enough.
I didn't check what rustc does, so maybe it does something more performant, like keeping track of only possibly problematic imports.
Fixes#18138.
Probably fixes#17630.
analysis-stats: respect `--disable-proc-macros` flag
I noticed that this flag wasn't being respected by `analysis-stats` when profiling proc macro expansion, so here's a small fix.
internal: Make COMPLETION_MARKER more explicitly r-a
If a user ever sees the completion marker, it's confusing to see text about IntelliJ. Use a string that's more explicitly about completion for rust-analyzer.
If a user ever sees the completion marker, it's confusing to see text
about IntelliJ. Use a string that's more explicitly about completion
for rust-analyzer.
Update to LLVM 19.1.0
This is a branch rebase of the submodule, now that LLVM 19.1.0 is final.
Our *only* extra patch right now is the one we're carrying for SGX unwind.
Apply `EarlyOtherwiseBranch` to scalar value
In the future, I'm thinking of hoisting discriminant via GVN so that we only need to write very little code here.
r? `@cjgillot`
internal: Disable GitHub releases for now
These are currently throwing `Error: HttpError: Resource not accessible by integration` because of the organization change, let's disable them for today's release.
Because it took me hours to figure out that contrary to common sense, the offset stored is the *end* of the node, and we search by the *start*. Which is why we need a convoluted `partition_point()` instead of a simple `binary_search()`. And this was not documented at all. Which made me make mistakes with my implementation of `SpanMap::merge()`.
The other bug fixed about span map merging is correctly keeping track of the current offset in presence of multiple sibling macro invocations. Unrelated, but because of the previous issue it took me hours to debug, so I figured out I'll put them together for posterity.
Mark `char::make_ascii_uppercase` and `char::make_ascii_lowercase` as const.
Relevant tracking issue: #130698
The `make_ascii_uppercase` and `make_ascii_lowercase` methods in `char` should be marked "const."
With the stabilisation of [`const_mut_refs`](https://github.com/rust-lang/rust/issues/57349/), this simply requires adding the `const` specifier to the function signatures.
fix rustc_nonnull_optimization_guaranteed docs
As far as I can tell, even back when this was [added](https://github.com/rust-lang/rust/pull/60300) it never *enabled* any optimizations. It just indicates that the FFI compat lint should accept those types for NPO.
rustc_llvm: adapt to flattened CLI args in LLVM
This changed in
llvm/llvm-project@e190d074a0. I decided to stick with more duplication between the ifdef blocks to make the code easier to read for the next two years before we can plausibly drop LLVM 19.
`@rustbot` label: +llvm-main
try-job: x86_64-msvc
rustc_expand: remember module `#[path]`s during expansion
During invocation collection, if a module item parsed from a `#[path]` attribute needed a second pass after parsing, its path wouldn't get added to the file path stack, so cycle detection broke. This checks the `#[path]` in such cases, so that it gets added appropriately. I think it should work identically to the case for external modules that don't need a second pass, but I'm not 100% sure.
Fixes#97589
The import is flagged as "indeterminate", and previously it was re-resolved, but only at the end of name resolution, when it's already too late for anything that depends on it.
This issue was tried to fix in https://github.com/rust-lang/rust-analyzer/pull/2466, but it was not fixed fully.
Fix anon const def-creation when macros are involved take 2
Fixes#130321
There were two cases that #129137 did not handle correctly:
- Given a const argument `Foo<{ bar!() }>` in which `bar!()` expands to `N`, we would visit the anon const and then visit the `{ bar() }` expression instead of visiting the macro call. This meant that we would build a def for the anon const as `{ bar!() }` is not a trivial const argument as `bar!()` is not a path.
- Given a const argument `Foo<{ bar!() }>` is which `bar!()` expands to `{ qux!() }` in which `qux!()` expands to `N`, it should not be considered a trivial const argument as `{{ N }}` has two pairs of braces. If we only looked at `qux`'s expansion it would *look* like a trivial const argument even though it is not. We have to track whether we have "unwrapped" a brace already when recursing into the expansions of `bar`/`qux`/any macro
r? `@camelid`
