Add rust_analyzer as a predefined tool

[Veykril]

Given all the other rust-lang tools have it, I'd expect r-a to have it too. (we have a few ideas for using this rust-lang/rust-analyzer#11556).

[rustbot]

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[ehuss]

If you add this, can you please update the recognized tool attributes in https://github.com/rust-lang/reference/blob/e356977fceaa8591c762312d8d446769166d4b3e/src/attributes.md#L199?

[BoxyUwU]

r? @ehuss

[Veykril]

rust-lang/reference#1498

[ehuss]

I am not the correct person to review this.

r? compiler

Also, I would expect this to go through the MCP process. This is adding a new attribute which can be used on stable.

I think there is still an open design question around how tools are registered, and I think caution should be used when adding more built-in attributes. I think there should be some mechanism for being able to support tool attributes that doesn't bake them into the language, or require different compiler implementations to also hard-code this list. My concern is that if I handed this code to some other compiler:

#[rustfmt::skip]
fn f() {}

should all implementations know what rustfmt is? What about the other tools listed here? If so, then that bakes that into the language, or else makes code non-portable (assuming an error is generated for an unknown attribute).

#66079 has implemented #![register_tool(my_tool)] for this purpose, but then do we expect anyone that uses clippy or rustfmt (or any of these other built-in-tools) to have to specify something like #![register_tool(clippy)]?

I'm not quite seeing how tools could be registered, while keeping code portable across implementations. One option would be to keep all tools in a tool namespace (like #[tool::rust_analyzer::foo]), and then ignore everything under tool (similar to the diagnostic namespace).

cc @petrochenkov FYI, not sure if you have an opinion here.

[petrochenkov]

From what I remember the existing tools were hardcoded because #![register_tool] wasn't yet stable, after it's stable all tools were supposed to be registered explicitly.
(I also missed the moment miri was added to the list.)

Is there any specific motivation for adding rust_analyzer to the list now?

[Veykril]

(I also missed the moment miri was added to the list.)

I saw the miri one being added without second thoughts and figured rust project tools would be just fine.

after it's stable all tools were supposed to be registered explicitly.

How would that even work? Removing them would break things so that doesn't seem like an option?

Is there any specific motivation for adding rust_analyzer to the list now?

rust-lang/rust-analyzer#11556 has a bunch of ideas listed, but if you ask right now there isn't a concrete plan yet. This would make experimenting for these feature for r-a nicer though. I'm fine with this being closed though for now, if we don't want to add every rust-project tool here (though as I read the register_tool issue it does feel like its ages away from ever being stabilized, and as eric pointed out, the feature is questionable designed in the first place)

[davidtwco]

I think this makes sense to do. Tools have been added to this list in the past without any broader approvals other than the review (most recently, miri in #124293), but I think we probably should do an MCP for this (and tools going forward). After that, r=me.

[petrochenkov]

How would that even work? Removing them would break things so that doesn't seem like an option?

They can be removed on an edition bump.