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
Extend ItemTree pretty-printing to include attributes even when a cfg
expression evaluates to false, emitting explicit `cfg(cfg_expr)` marker
after the attributes.
This improves testability of ItemTree attribute handling by exposing
more information in pretty-printed output.
Changes:
- `const_of_item()` was added to `Interner`, analogous to `type_of()`. No strongly-typed ID (yet).
- New solver trait lang item: `TrivialClone`.
- `TypeRelation` changed a bit, the code was copied from rustc.
Introduce `NO_DOWNMAP_ERASED_FILE_AST_ID_MARKER`, which prevents `Span`s
from being mapped down into macro expansions.
This is a preparatory step for adding a new field to the
`rust-project.json` format that can inject crate-level attributes.
`Span`s for those attributes will be marked with
`NO_DOWNMAP_ERASED_FILE_AST_ID_MARKER`, indicating that they should not
be mapped down into macro expansions.
Which can happen when two workspaces are opened, by only considering impls from dependencies of this crate.
I have no idea how to construct a test for this, but I tested it manually and it works.
Example
---
```rust
fn main() {
$0let x = true && false;
}
```
**Before this PR**
```rust
fn main() {
if let x = true {
}
}
```
**After this PR**
```rust
fn main() {
if let x = (true && false) {
}
}
```
Don't leak sysroot crates through dependencies
Previously if a dependency of the current crate depended on a sysroot crate, then `extern crate` would in the current crate would pick the first loaded version of said sysroot crate even in case of an ambiguity. This is surprising and brittle. For `-Ldependency=` we already blocked this since rust-lang/rust#110229, but the fix didn't account for sysroot crates.
Should fix https://github.com/rust-lang/rust/issues/147966
