Commits on May 18, 2021

1. Stabilize extended_key_value_attributes …

    # Stabilization report
   
    ## Summary
   
   This stabilizes using macro expansion in key-value attributes, like so:
   
    ```rust
    #[doc = include_str!("my_doc.md")]
    struct S;
   
    #[path = concat!(env!("OUT_DIR"), "/generated.rs")]
    mod m;
    ```
   
   See the changes to the reference for details on what macros are allowed;
   see Petrochenkov's excellent blog post [on internals](https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455)
   for alternatives that were considered and rejected ("why accept no more
   and no less?")
   
   This has been available on nightly since 1.50 with no major issues.
   
    ## Notes
   
    ### Accepted syntax
   
   The parser accepts arbitrary Rust expressions in this position, but any expression other than a macro invocation will ultimately lead to an error because it is not expected by the built-in expression forms (e.g., `#[doc]`).  Note that decorators and the like may be able to observe other expression forms.
   
    ### Expansion ordering
   
   Expansion of macro expressions in "inert" attributes occurs after decorators have executed, analogously to macro expressions appearing in the function body or other parts of decorator input.
   
   There is currently no way for decorators to accept macros in key-value position if macro expansion must be performed before the decorator executes (if the macro can simply be copied into the output for later expansion, that can work).
   
    ## Test cases
   
    - https://github.com/rust-lang/rust/blob/master/src/test/ui/attributes/key-value-expansion-on-mac.rs
    - https://github.com/rust-lang/rust/blob/master/src/test/rustdoc/external-doc.rs
   
   The feature has also been dogfooded extensively in the compiler and
   standard library:
   
   - rust-lang#83329
   - rust-lang#83230
   - rust-lang#82641
   - rust-lang#80534
   
    ## Implementation history
   
   - Initial proposal: rust-lang#55414 (comment)
   - Experiment to see how much code it would break: rust-lang#67121
   - Preliminary work to restrict expansion that would conflict with this
   feature: rust-lang#77271
   - Initial implementation: rust-lang#78837
   - Fix for an ICE: rust-lang#80563
   
    ## Unresolved Questions
   
   ~~rust-lang#83366 (comment) listed some concerns, but they have been resolved as of this final report.~~
   
    ## Additional Information
   
    There are two workarounds that have a similar effect for `#[doc]`
   attributes on nightly. One is to emulate this behavior by using a limited version of this feature that was stabilized for historical reasons:
   
   ```rust
   macro_rules! forward_inner_docs {
       ($e:expr => $i:item) => {
           #[doc = $e]
           $i
       };
   }
   
   forward_inner_docs!(include_str!("lib.rs") => struct S {});
   ```
   
   This also works for other attributes (like `#[path = concat!(...)]`).
   The other is to use `doc(include)`:
   
   ```rust
    #![feature(external_doc)]
    #[doc(include = "lib.rs")]
    struct S {}
   ```
   
   The first works, but is non-trivial for people to discover, and
   difficult to read and maintain. The second is a strange special-case for
   a particular use of the macro. This generalizes it to work for any use
   case, not just including files.
   
   I plan to remove `doc(include)` when this is stabilized. The
   `forward_inner_docs` workaround will still compile without warnings, but
   I expect it to be used less once it's no longer necessary.

   

   jyn514 committed May 18, 2021
   Configuration menu

   • View commit details
   • Copy full SHA for e48b6b4
   • Browse repository at this point

   Copy the full SHA

   e48b6b4 View commit details

   Browse the repository at this point in the history