[DRAFT] RFC: cfg(attr(...))

[Centril]

Rendered

This is a draft version of an RFC for you to review, before a formal proposal is made for consideration.

[Nemo157]

Is there any way this could handle enhancements to attributes, rather than just their initial minimal version? For example the nightly #[doc(include = "foo.md")] feature (I feel like the #[doc] attribute has had other properties added to it in the past as well), or the #[cfg_attr] w/ list of attributes RFC.

[Centril]

Note to self: One could in some special cases extend attr(..) and write something like attr(doc(include)). However, as attribute macros can be procedural macros written in Rust one must run the procedural macro behind doc to see if it would apply or not; however, since Rust is turing complete, such analysis is in general undecidable.

[joshtriplett]

You should mention that cfg(not(attr(...)), ...) also works.

Otherwise, LGTM; ship it!

[joshtriplett]

Oh, one other issue: you need to explicitly explain that this checks if the attribute in question is usable in the context in which it was used. For instance, must_use has worked on types for a long time; the ability to use it on functions arrived much later. cfg(attr(must_use), must_use) on a function needs to check if the attribute works on a function.

[Centril]

Further note to self based on discussion with @Havvy: should attr(..) be restricted to built-in attributes to keep cfg stripping independent of resolution order and defer uses for built-in macros to accessible(::user::macro)? That might be a cleaner and more orthogonal solution and could also solve problems wrt. undecidability of things like attr(optimize(size)) since built-in attributes can be known to be context free instead of turing complete.