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.

[traviscross]

@rustbot labels +I-lang-nominated +T-lang

Generally the attribute namespace is a lang concern, so let's nominate for lang to decide on the handling here.

[joshtriplett]

@Veykril 👍 for having an attribute namespace for rust-analyzer. Do you want this to be rust_analyzer, or just analyzer?

[Veykril]

Well the tool is called rust-analyzer so it should be rust_analyzer :)

[traviscross]

@rustbot labels -I-lang-nominated

We discussed this in the lang triage call today.

We affirmed that lang owns the attribute namespace, and so these additions require lang approval.

(We're discussing various policies that would perhaps delegate these decisions in certain cases or reframe the problem so that these additions for tools weren't needed, but those all are all future work.)

On this question specifically, for rust-analyzer, we're OK with adding rust_analyzer (or analyzer, if that were to be preferred) as a predefined tool as this PR does. Consequently, this PR is OK to move forward as far as lang is concerned.

In terms of the general principles on which we're accepting this and would consider others in the future, we discussed that the ones we add must have rules for what is valid that we are willing to encode into rustc, and so, therefore, in practice the tool will need to be part of the Rust project or be some other well-known crate.

In terms of a broader scheme that could obviate needing to add these, we discussed both the "worse is better" approach of, e.g. allowing any attribute with :: (or some other similarly permissive rule), and the "better is better" approach of having something type checked, e.g. along the lines of Java's similar attributes.

[davidtwco]

@bors r+

[bors]

📌 Commit 4c5e954 has been approved by davidtwco

It is now in the queue for this repository.

[matthiaskrgr]

@bors r-
needs x.py fmt 😿

[davidtwco]

@bors r+

[bors]

📌 Commit 3390159 has been approved by davidtwco

It is now in the queue for this repository.

[workingjubilee]

@bors r-