Changed package.json so vscode extension settings have submenus
There are a lot of options that are a part of rust-analyzer, sometimes it can be hard to find an option that you are looking for. To fix this I have put all configurations into categories based on their names. I have also changed the schema in `crates/rust-analyzer/src/config.rs` to reflect this.
Currently for each generated entry the title is redeclared, this does function but I am prepared to change this if it is a problem.
fix: Highlight unlinked files consistently with inactive files
Currently, rust-analyzer highlights the entire region when a `cfg` is inactive (e.g. `#[cfg(windows)]` on a Linux machine). However, unlinked files only highlight the first three characters of the file.
This was introduced in #8444, but users have repeatedly found themselves with no rust-analyzer support for a file and unsure why (see e.g. #13226 and the intentionally prominent pop-up added in PR #14366).
(Anecdotally, we see this issue bite our users regularly, particularly people new to Rust.)
Instead, highlight the entire inactive file, but mark it as all as unused. This allows users to hover and run the quickfix from any line.
Whilst this is marginally more prominent, it's less invasive than a pop-up, and users do want to know why they're getting no rust-analyzer support in certain files.
Before (note the subtle grey underline is only at the beginning of the first line):
After (user can hover and fix from any line):
chore: Update Cargo.lock to avoid yanked version
Building rust-analyzer currently generates a warning because libc 0.2.154 has been yanked. Update to 0.2.155 in Cargo.lock.
Currently, rust-analyzer highlights the entire region when a `cfg` is
inactive (e.g. `#[cfg(windows)]` on a Linux machine). However,
unlinked files only highlight the first three characters of the file.
This was introduced in #8444, but users have repeatedly found
themselves with no rust-analyzer support for a file and unsure
why (see e.g. #13226 and the intentionally prominent pop-up added in
PR #14366).
(Anecdotally, we see this issue bite our users regularly, particularly
people new to Rust.)
Instead, highlight the entire inactive file, but mark it as all as
unused. This allows users to hover and run the quickfix from any line.
Whilst this is marginally more prominent, it's less invasive than a
pop-up, and users do want to know why they're getting no rust-analyzer
support in certain files.
Feat: hide double underscored symbols from symbol search
Fixes#17272 by changing the default behavior of query to skip results that start with `__` (two underscores).
Not sure if this has any far reaching implications - a review would help to understand if this is the right place to do the filtering, and if it's fine to do it by default on the query.
If you type `__` as your search, then we'll show the matching double unders, just in case you actually need the symbol.
Make TLS accessors closures that return pointers
The current TLS macros generate a function that returns an `Option<&'static T>`. This is both risky as we lie about lifetimes, and necessitates that those functions are `unsafe`. By returning a `*const T` instead, the accessor function do not have safety requirements any longer and can be made closures without hassle. This PR does exactly that!
For native TLS, the closure approach makes it trivial to select the right accessor function at compile-time, which could result in a slight speed-up (I have the hope that the accessors are now simple enough for the MIR-inliner to kick in).
Show files produced by `--emit foo` in json artifact notifications
Right now it is possible to ask `rustc` to save some intermediate representation into one or more files with `--emit=foo`, but figuring out what exactly was produced is difficult. This pull request adds information about `llvm_ir` and `asm` intermediate files into notifications produced by `--json=artifacts`.
Related discussion: https://internals.rust-lang.org/t/easier-access-to-files-generated-by-emit-foo/20477
Motivation - `cargo-show-asm` parses those intermediate files and presents them in a user friendly way, but right now I have to apply some dirty hacks. Hacks make behavior confusing: https://github.com/hintron/computer-enhance/issues/35
This pull request introduces a new behavior: now `rustc` will emit a new artifact notification for every artifact type user asked to `--emit`, for example for `--emit asm` those will include all the `.s` files.
Most users won't notice this behavior, to be affected by it all of the following must hold:
- user must use `rustc` binary directly (when `cargo` invokes `rustc` - it consumes artifact notifications and doesn't emit anything)
- user must specify both `--emit xxx` and `--json artifacts`
- user must refuse to handle unknown artifact types
- user must disable incremental compilation (or deal with it better than cargo does, or use a workaround like `save-temps`) in order not to hit #88829 / #89149
internal: Improve `find_path` performance
cc https://github.com/rust-lang/rust-analyzer/issues/17339, db80216dac should fix a case where we don't reduce our search space appropriately. This also adds a fuel system which really shouldn't ever be hit, hence why it warns
Don't mark `#[rustc_deprecated_safe_2024]` functions as unsafe
`std::env::set_var` will be unsafe in edition 2024, but not before it. I couldn't quite figure out how to check for the span properly, so for now we just turn the false positives into false negatives, which are less bad.
Add `Function::fn_ptr_type(…)` for obtaining name-erased function type
The use case of this function if being able to group functions by their function ptr type.
cc `@flodiebold`
fix: Only generate snippets for `extract_expressions_from_format_string` if snippets are supported
Part of #17332
Fixes `extract_expressions_from_format_string` so that it doesn't generate snippets if the client doesn't support it.
Use parenthetical notation for `Fn` traits
Always use the `Fn(T) -> R` format when printing closure traits instead of `Fn<(T,), Output = R>`.
Address #67100:
```
error[E0277]: expected a `Fn()` closure, found `F`
--> file.rs:6:13
|
6 | call_fn(f)
| ------- ^ expected an `Fn()` closure, found `F`
| |
| required by a bound introduced by this call
|
= note: wrap the `F` in a closure with no arguments: `|| { /* code */ }`
note: required by a bound in `call_fn`
--> file.rs:1:15
|
1 | fn call_fn<F: Fn() -> ()>(f: &F) {
| ^^^^^^^^^^ required by this bound in `call_fn`
help: consider further restricting this bound
|
5 | fn call_any<F: std::any::Any + Fn()>(f: &F) {
| ++++++
```
