Allow struct and enum to contain inner attrs

[dtolnay]

Previously inner attributes have been supported in modules and functions ever since Rust 1.0.0:

mod m {
    #![doc = ""]
}

extern "C" {
    #![doc = ""]
}

fn f() {
    #![doc = ""]
}

and in traits since Rust 1.43.0 (#68728):

trait T {
    #![doc = ""]
}

This PR extends the Rust parser to additionally handle inner attributes inside of structs, enums, and unions.

struct S {
    #![doc = ""]
}

enum E {
    #![doc = ""]
}

union U {
    #![doc = ""]
}

Rationale: I am interested in applying this syntax in https://github.com/dtolnay/cxx, for example for pulling enum variant names and discriminant values out of a Clang AST dump. Allowing the attribute to go where the variants go is more evocative than putting it outside of the enum.

#[cxx::bridge]
mod ffi {
    extern "C++" {
        include!("path/to/header.h");
    }

    ...

    enum Enum {
        #![variants_from_header]
    }
}

[rust-highfive]

r? @petrochenkov

(rust-highfive has picked a reviewer for you, use r? to override)

[scottmcm]

It feels a bit weird to do this after also having removed it from things like match in #83312

[Aaron1011]

I'm fairly indifferent to the question of inner attributes in general. Personally, I've never felt the need to write an inner attribute instead of an outer attribute (except at the crate root).

One of the rationales for #83312 is to reduce the places where inner attributes can occur in an expression, allowing us to use a simple lookahead check to determine if inner attributes are even possible during expression parsing. However, that does not apply here - in general, items can already support inner attributes, so we don't have any logic in place to bail out of token collection early. Also, there are significantly more expressions than items in any normal program, so there are fewer performance gains to be had by avoiding work during the parsing of items.

[petrochenkov]

With #83312 we get a simple rule for where inner attributes are supported - in all containers for statements (or some subset of statements), this PR makes the rule somewhat random again.

Given the number of issues with inner attributes (e.g. #54726 or token collection) I'd personally only allow them when there's no other choice - at the crate root (+ perhaps out-of-line modules) if we were designing things from scratch.
In other cases making attributes inner doesn't make much difference in functionality or readability, they would still be only a couple of lines away from their outer equivalents.
So I generally don't support the idea of supporting inner attributes in more places.

[dtolnay]

• Rebase to resolve conflict with Improve diagnostics for functions in struct definitions #76808 in compiler/rustc_parse/src/parser/item.rs.

[dtolnay]

Linking some closely related discussion on where and how to support inner attributes: #84879.

[m-ou-se]

I personally 'parse' #![attr] mostly like an item just like use ..; and type T = ..; etc. So I'd expect to see these as part of a bunch of items. E.g.

#![attr]
use a::b;
type X = i32;
fn x() ->X;

Structs, enums, and unions are only a comma-separated list of members/variants, not containers of all kind of items like traits and modules are. So an 'item' like #![attr] directly followed by the comma-separated list seems very odd to me.

Allowing the attribute to go where the variants go is more evocative than putting it outside of the enum.

I suppose that same argument could be made for putting methods inside a struct body too, but that's not something that would syntactically work very well either.

[dtolnay]

I don't find "like an item, seen as part of a bunch of items" to be a beneficial intuition for inner attributes. That would heavily imply:

1. that they are order insensitive:

   pub trait Trait {...}
   
   #![lol]

2. that they can have attributes:

   /// this doc comment documents the following attribute.
   #![no_std]

neither of which is realistic. If anything, it seems beneficial to help people out of the mental model of inner attributes as items.

[Mark-Simulacrum]

Dropping I-nominated -- discussed in last week's lang meeting, waiting on @joshtriplett for a summary on this PR of that discussion.

[dtolnay]

This observation from https://github.com/rust-lang/lang-team/blob/023fa403807f298d45753077eb6528219ce9aadf/minutes/2021-06-29.md#allow-struct-and-enum-to-contain-inner-attrs-rust84414 is not accurate:

@scottmcm: because it's all in the macro anyway, it could do arbitrary tokens too?

enum Foo { .. from header .. }

Attribute macro input is required to be syntactically valid Rust (and I would hate for that to change). Otherwise this PR already wouldn't be necessary, as #![...] are tokens too.

[bors]

☔ The latest upstream changes (presumably #93594) made this pull request unmergeable. Please resolve the merge conflicts.

[dtolnay]

• Rebase to resolve conflict with better suggestion for duplicated where clause #93571

[joshtriplett]

We discussed this again in today's @rust-lang/lang meeting.

In general, we didn't feel enthusiastic about adding inner attributes in more places than those already supported, particularly where outer attributes are already an option.

I appreciate that being able to put a token inside the enum braces is evocative in this case, where variants are being generated by the attribute. However, we'd like to avoid adding more variation here in a direction that we've previously shifted away from, and we find @petrochenkov's comments compelling here.

@rfcbot close

[rfcbot]

Team member @joshtriplett has proposed to close this. The next step is review by the rest of the tagged team members:

• @cramertj
• @joshtriplett
• @nikomatsakis
• @pnkfelix
• @scottmcm

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[nikomatsakis]

@rfcbot reviewed

I see the appeal of inner attribute, but indeed I find @petrochenkov's concerns valid, and the use case seems insufficiently compelling right now to add any risk of doing something we might regret.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to close, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.