feat: introduce crate_attrs field in rust-project.json

[J3m3]

Since the commit 5038446
("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

[J3m3]

I deliberately excluded lint attribute support in this PR, since it would involve a change to the public API. It might deserve a dedicated PR for discussion, since I'm not yet sure it's worth pursuing. Please let me know if anyone thinks this is the better place for it.

[ChayimFriedman2]

We don't hesitate too much before breaking our public API (it's explicitly not stable), especially an API like that that is basically directly intended at its single consumer.

[J3m3]

We don't hesitate too much before breaking our public API (it's explicitly not stable), especially an API like that that is basically directly intended at its single consumer.

I see, thanks! Then I'll add it here.

[ChayimFriedman2]

Left some comments.

[ChayimFriedman2]

Just one nit, then LGTM.

[ChayimFriedman2]

I feel like this doesn't test well that only the chosen attributes are collected. Instead assert that the item tree pretty-printed is equal to the collected attributes. Same for the following test.

[J3m3]

Then the result would just look like the below:

#[test]
fn crate_attrs_with_disabled_cfg_injected() {
    check(
        r#"
//- /main.rs crate:foo crate-attr:no_std crate-attr:cfg(false) crate-attr:features(f16,f128) crate-attr:crate_type="bin"
        "#,
        expect![[r#"
            #[cfg(false)]
        "#]]
    );
}

This is because the pretty-print short-circuits when it sees AttrsOrCfg::CfgDisabled.

[J3m3]

I already managed to fix this by the way, though I think it isn't perfect for now... let me re-check.

[ChayimFriedman2]

You can change it to print the attributes before :)

[J3m3]

You can change it to print the attributes before :)

Sorry, but could you elaborate?

[ChayimFriedman2]

It's fine if you don't want to, but the code is at

rust-analyzer/crates/hir-def/src/item_tree/pretty.rs

Line 89 in 34fd9f6

let AttrsOrCfg::Enabled { attrs } = attrs else {

and can be changed to also print the attributes (then #[cfg(false)], or even #[cfg(cfg_expr)] if you feel brave).

[J3m3]

Done implementing including #[cfg(cfg_expr)] printing. Would you like this to be a separate PR? I think this has a user-visible impact on "Feature: Debug ItemTree".

rust-analyzer/crates/ide/src/view_item_tree.rs

Lines 11 to 15 in 02f53e8

	pub(crate) fn view_item_tree(db: &RootDatabase, file_id: FileId) -> String {
	let sema = Semantics::new(db);
	let file_id = sema.attach_first_edition(file_id);
	db.file_item_tree(file_id.into()).pretty_print(db, file_id.edition(db))
	}

[ChayimFriedman2]

Whatever you prefer.