#[rust_analyzer::skip] attribute

[lnicola]

Though an annotation like #[rustanalyzer::skip] would be nice for some fuctions we do not want to be analyzed.

Originally posted by @giftal in #4500 (comment)

[lnicola]

This could also be a #[cfg(not(rust-analyzer))], though it's less obvious.

As for the effect, I'm not sure. We'd like to skip that item or expression completely, but we still need to parse it to see where it ends. In the linked issue we run into a step limit in the parser.

[lnicola]

Another option would be to move the problematic code to a different file and mark it as excluded, although that's still editor-dependent for now.

[giftal]

Noted, thank you.

[jonas-schievink]

Note that this requires upstream support in order to register rust_analyzer as a tool attribute namespace. A cfg would be easier to implement.

[jyn514]

Note that this requires upstream support in order to register rust_analyzer as a tool attribute namespace.

This would be useful as a general feature I think, other people have also asked for it: https://internals.rust-lang.org/t/pre-rfc-implementation-defined-lints/13870/10

[jyn514]

Note that this requires upstream support in order to register rust_analyzer as a tool attribute namespace. A cfg would be easier to implement.

You can do this on nightly with register_tool: rust-lang/rust#66079

[ChayimFriedman2]

It may also apply to proc macros instead of (or in addition to) the current setting rust-analyzer.procMacro.ignored.

[bjorn3]

I think rust-analyzer.procMacro.ignored is a more personal preference and thus shouldn't be dictated by the upstream (which an ignore in the actual source would do) I think. Some proc macros are only partially broken under rust-analyzer in which case some would like it enabled and others would like it disabled. In addition versions of rust-analyzer released after the crate was published may fix the proc macro.

[ChayimFriedman2]

I think rust-analyzer.procMacro.ignored is a more personal preference and thus shouldn't be dictated by the upstream (which an ignore in the actual source would do) I think. Some proc macros are only partially broken under rust-analyzer in which case some would like it enabled and others would like it disabled. In addition versions of rust-analyzer released after the crate was published may fix the proc macro.

But there are macros that does not need expansion at all (e.g. tokio::main, at least until we'll emit an error for bare async fn main()), and expanding them is just redundant.

In a second thought, however, maybe all of those macros, even if should not be expanded today, should be in the future when we'll implement full diagnostics support.

[Veykril]

#18907 implements such an attribute for bodies, that is functions / consts / statics for now. We do not make any stability promises wrt to the attribute for the time being though (although it is unlikely to change behavior or syntax in this case)

[jyn514]

#18907 implements such an attribute for bodies, that is functions / consts / statics for now. We do not make any stability promises wrt to the attribute for the time being though (although it is unlikely to change behavior or syntax in this case)

@Veykril i am confused: how do you expect people to add #[rust_analyzer::skip] to their source code? is the idea for each crate to add register_tool to the crate root?

(i would like to improve the situation around register_tool, i'm aware it's a pain. but i'm asking about how RA works today.)

[Veykril]

rust_analyzer is special cased like rustfmt etc so the compiler just accepts it as is rust-lang/rust#125241

[ChayimFriedman2]

@Veykril Should we close this given it's implemented?