extended_key_value_attributes cannot be enabled conditionally
#82768
Comments
jyn514
added
A-macros
|
It's possible to check the predicate first and parse the rest of |
|
The workaround is to add one more layer of #![cfg_attr(FALSE, cfg_attr(TRUE, doc = include_str!("../README.md")))] // OK |
Thanks! Would it be possible to add that as a structured suggestion in the parser? I can take a look at this weekend if you think it's a good idea :) |
|
I don't think it's a reasonable investment of time, especially given that we'll be able to stabilize |
camelid
added
the
F-extended_key_value_attributes
|
@daxpedda In what scenario are you checking for the feature existence? In clap, I do: #![cfg_attr(feature = "doc", feature(external_doc))]
#![cfg_attr(feature = "doc", doc(include = "../README.md"))] |
|
@pksunkara |
|
My bad, I meant to paste the updated one as a probable workaround for people who run into the above bug when they don't need to check the feature existence #![cfg_attr(feature = "doc", feature(extended_key_value_attributes))]
#![cfg_attr(feature = "doc", doc = include_str!("../README.md"))] |
|
@pksunkara that has the same issue, when the |
|
So, my understanding of the workaround is that you would write it like this: #![cfg_attr(feature = "doc", feature(extended_key_value_attributes))]
#![cfg_attr(feature = "doc", cfg_attr(feature = "doc", doc = include_str!("../README.md")))]This compiles all the way back to (edit: Given that this is related to the behaviour of existing compilers, I don't see that there is any change that could happen in new compilers to mitigate it, other than changing the syntax, which would sort of defeat the point of just reusing the existing syntax). |
…=petrochenkov Stabilize extended_key_value_attributes Closes rust-lang#44732. Closes rust-lang#78835. Closes rust-lang#82768 (by making it irrelevant). # 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 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 (rust-lang#82539). The `forward_inner_docs` workaround will still compile without warnings, but I expect it to be used less once it's no longer necessary.
Yep, don't ask me, that seems to be the way to do it: rust-lang/rust#82768
I tried this code:
I expected to see this happen: The compiler gives no error, because
doc = include_str!should only be compiled if the predicate is true.Instead, this happened: The compiler gives an error that
extended_key_value_attributesis unstable.I guess this happens because the compiler has to parse the attribute even if the cfg is false? @petrochenkov is giving an error here intentional?
Meta
rustc --version: 1.52.0-nightly (2021-03-01 4f20caa)cc #78835
Originally posted by @daxpedda in #82539 (comment)
The text was updated successfully, but these errors were encountered: