Since the commit 50384460c68f
("Rewrite method resolution to follow rustc more closely"), the method
resolution logic has changed: rust-analyzer only looks up inherent
methods for primitive types in sysroot crates.
Unfortunately, this change broke at least one project that relies on
`rust-project.json`: Rust-for-Linux. Its auto-generated
`rust-project.json` directly embeds `core`, `alloc`, and `std` in the
`crates` list without defining `sysroot_src`. Consequently,
rust-analyzer fails to identify them as sysroot crates, breaking IDE
support for primitive methods (e.g., `0_i32.rotate_left(0)`).
However, specifying `sysroot_src` creates a new issue: it implicitly
adds `std` as a dependency to all kernel module crates, which are
actually compiled with `-Zcrate-attr=no_std`. Since rust-analyzer cannot
see compiler flags passed outside of the project definition, we need a
method to explicitly specify `#![no_std]` or, more generally,
crate-level attributes through the project configuration.
To resolve this, extend the `rust-project.json` format with a new
`crate_attrs` field. This allows users to specify crate-level attributes
such as `#![no_std]` directly into the configuration, enabling
rust-analyzer to respect them when analyzing crates.
References:
- The original Zulip discussion:
https://rust-lang.zulipchat.com/#narrow/channel/185405-t-compiler.2Frust-analyzer/topic/Primitive.20type.20inherent.20method.20lookup.20fails/with/562983853
In the inferred type hints, expand the line too long. add config to disable it.
Example
---
```json
{"rust-analyzer.inlayHints.typeHints.hideInferredTypes": true}
```
```rust
use std::collections::HashMap;
fn foo(iter: Vec<Result<HashMap<String, String>, std::io::Error>>) {
let output = iter.into_iter().collect::<Result<Vec<_>, _>>().unwrap();
}
```
**Before this PR**
```rust
let output: Vec<HashMap<String, String>> = iter.into_iter().collect::<Result<Vec<_ = HashMap<String, String>>, _ = Error>>().unwrap();
```
**After this PR**
```rust
let output: Vec<HashMap<String, String>> = iter.into_iter().collect::<Result<Vec<_>, _>>().unwrap();
```
I don't do it by default, for three reasons: (1) it's more expensive, (2) I actually quite like seeing the derives, and they may expand to no impl/more than one impl, (3) if #19130 will ever be merged this will become even more useful.
Even a config might be too much, but it was fun and easy to code so I did that.
The first sentence a new user should see should ideally answer the
questions:
* What is rust-analyzer?
* Why might I want to use it?
The vast majority of users will be interested in using rust-analyzer
inside their favourite editor. We should clarify that rust-analyzer is
an LSP implementation and that it supports all the classic IDE
features.
Whilst it's also true that rust-analyzer is modular and organised into
libraries, the first impression should (I think) focus on an overview
and the primary use case.
Reborrows are consecutive deref then ref. Make it the default because reborrows are mostly useless to the programmer.
Also rename `rust-analyzer.inlayHints.expressionAdjustmentHints.enable: "reborrow"` to `rust-analyzer.inlayHints.expressionAdjustmentHints.enable: "borrows"`, as it's not about reborrows but about any ref/deref and it's confusing with the new setting.
- All settings are now phrased in the imperative form stating what the
setting does rather than talking about what it controls. (E.g.:
"Show `Debug` action." instead of "Whether to show `Debug` action"
- Categories are now displayed in title case
- Categories are now sorted lexicographically
- General category is removed (and all the settings are moved to the top
level)
- Language for a few descriptions is made a bit less ambiguous
