Tracking issue for custom inner attributes

[alexcrichton]

Added in #54093 inner attributes are not allowed to be procedural macros right now, and this issue is tracking that feature of procedural macros!

Assistance in filling in this issue would be greatly appreciated!
UPDATE: #54726 (comment) below contains the detailed description.

[dhardy]

Summary:

error[E0658]: non-builtin inner attributes are unstable (see issue #54726)
 --> src/lib.rs:3:1
  |
3 | #![foo]
  | ^^^^^^^
  |
  = help: add #![feature(custom_inner_attributes)] to the crate attributes to enable

error[E0658]: The attribute `foo` is currently unknown to the compiler and may have meaning added to it in the future (see issue #29642)
 --> src/lib.rs:3:4
  |
3 | #![foo]
  |    ^^^
  |
  = help: add #![feature(custom_attribute)] to the crate attributes to enable

[petrochenkov]

(I'll fill in details about why this is unstable soon.)

[petrochenkov]

So, the primary open question about inner attributes is what scope they are resolved in.

For example:

use xxx::attr;

mod m {
    #![attr]

    use yyy::attr;
}

Does #![attr] refer to xxx::attr or yyy::attr?

Right now, #![attr] is resolved from outside of the module in the same way as outer attributes (with exception of the crate attributes maybe, not sure).

However, if something is inside a module (or block, etc) it's normally reasonable to expect that it's resolved from inside of that module as well.
IIRC, @nrc argued for applying this logic to attributes too (UPDATE: this happened in #41430).

With attributes such resolution from the inside causes problems though.

---

First of all, there's no "inside" before we expand all the macro attributes.

mod m {
    #![attr]
    
    /* items */
}

is just a token stream, even if it looks like module and items, it effectively doesn't exist in the module structure of the crate yet.

#![attr] can transform that token stream in any way, for example turn module into a block, or struct, or even into nothing, possibly invalidating our "inner" resolution for attr even if we somehow obtained it speculatively from the unexpanded mod m.

---

Possible solutions to this problem:

• Keep status quo and resolve inner attributes from the outside (i.e. treat them purely as syntactic sugar for the "true form" - outer attributes).
  This is the simplest and most straightforward solution.
  Some details need to be figured out for crate attributes though - what exactly is the "outer scope" for the crate root (apparently it's preludes/builtins, but some prelude names actually come from items in the root module) and whether compiler-injected stuff counts as input for macros in this position.

• Resolve from the inside, but prohibit macro attributes in inner attribute positions.
  This way we can be sure that the item to which the attribute is attached is fixed after all its outer attributes are expanded, so we can add it to the module structure of the crate immediately.
  Later, if the attribute does resolve to a macro, we can report an error.
  It turns out this is not entirely backward compatible, things like

  fn test() {
      #![test]
  
      /* body */
  }

  are already used in practice, even in the compiler itself.
  I expect the "no-macro" condition also being perceived as restrictive, given that some people want macros to work even at crate level (!) (Attribute macros invoked at crate root have issues #41430).

• Use the outer resolution for expanding #![attr], but then validate that the inner resolution after expansion gives the same result.
  This gives effectively the same result as status quo, but with future-proofing.
  I think this would be a great way forward, because it allows to remove the feature gate without having to decide on the outer vs inner question right now.

• Use the inner resolution before expansion for expanding #![attr], but then validate that the inner resolution after expansion gives the same result.
  This requires full-blown speculative eager expansion and we don't have it right now.
  We have some form of eager expansion in the compiler, but it's very ad-hoc, buggy and unhygienic, so it's suitable only for very simple stuff a la env!(stringify!(something)).

[petrochenkov]

Use the outer resolution for expanding #![attr], but then validate that the inner resolution after expansion gives the same result.

This variant is the way to go right now, I think.

[dhardy]

The caveat is that adding use yyy::attr; into the inner module may cause breakage. Overall though it seems a reasonable compromise.