`#[rust_analyzer::*]` tool and lint attributes

[Veykril]

NOTE: Implementation of some of these has started but we do not make any stability guarantees about these attributes for now, so they may change over time.

• Tracking issue for #![register_tool] rust#66079

This serves as a general bag of ideas around possible future r-a/ide tool attributes (we have this attribute now rust-lang/rust#125241)

• #[rust_analyzer::skip]: cc #[rust_analyzer::skip] attribute #7449
• #[rust_analyzer::macro::expands_to(kind0, kind1, ...)] where kind can be anything a macro is allowed to expand to like item, expr, pat, ... This annotation's sole purpose would be to aid completions by allowing us to filter out macros that aren't applicable.
• #[rust_analyzer::crate_prelude] marks a crate's prelude, aids fly-import completions and auto-import features by allowing (via a config) to avoid or prefer crate preludes for imports.
• #[rust_analyzer::rust_fixture_params(param_name1, ...)]: specify parameters of a function that are to be highlighting injected, alternatively mark the parameters with attributes directly, but that might become rather unwieldy -> feat: Re-implement rust string highlighting via tool attribute #18906
• #[rust_analyzer::macro::expansion_type(path::to::type)]: unit-returning macros in statement position should be completed with a semicolon #10913
• #[rust_analyzer::unsafe_macro]: https://www.reddit.com/r/rust/comments/vftkrm/unsafe_code_highlighting_with_rustanalyzer/icy0jlv/
• #[rust_analyzer::render_as_impl_trait]: annotation for types to render them as impl Trait, like we do by default for std types that implement Iterator
• #[rust_analyzer::color(args)]: Document Color support #13122
• #[rust_analyzer::resolve_hint(path::to::something): Will make r-a attempt to resolve the given path, useful for macros to output to so that tokens they full consume can be remapped to a resolving path.
• #[rust_analyzer::runnable(command arg arg ....)): Will make r-a recognize this as a runnable action (like fn main() or #[test] fn test), putting a runnable lens on top that executes the command with the given args
• #[rust_analyzer::macro_expansion_token_limit(10000)]: Sets the expansion token limit for the crate or annotated macro call
• #[rust_analyzer::enum_happy_variant]: Annotate variants to handle them like Some or Ok for assist purposes, https://github.com/rust-lang/rust-analyzer/blob/d6d735e6f20ef78b16a79886fe28bd69cf059504/crates/ide-db/src/ty_filter.rs

Note: names are of course bikesheddable

[bjorn3]

There are a couple special cases for rust-analyzer's own code which could be migrated to an attribute I think. For example getting code highlighting inside test fixture strings.

[Veykril]

That's a good point, added that to the list.

[ModProg]

I am not sure if this fits here as well, but a way for a derive macros helper atteibutes or proc macros in general to define what their input is.

e.g. tell RA that your macro looks like this:

#[attr(param1=<usize>, param2=<syn::Path>)]

Especially proc macro devwlopers would probably be fine to go the extra step to manually define their macros input syntax (as well as maybe a way to skip expansion for a macro that could tell ra it only e.g. implements a Trait).

An this could even be delegated to parsing libraries like attribute-derive.

[Veykril]

We could have some very very minor grammar for specifying things here, but that won't do much for more complex cases.

I'm not sure what you mean with delegating to parsing libraries.

[ModProg]

I'm not sure what you mean with delegating to parsing libraries.

Generating the attribute with the gramar. So the proc macro developer would not need to write it on their own.

Of course, at that point the parsing library could also handle the completion without depending on such a grammar, if setup correctly. Using something like #7402 (comment)