Description
A version of my crate parse-mediawiki-sql with macro-generated docs builds on stable, but errors out on nightly, where the error suggests that I fix the error by enabling #![feature(extended_key_value_attributes)]
.
Stable is cargo 1.52.0 (rust-lang/cargo@69767412a 2021-04-21), rustc 1.52.1 (9bc8c42 2021-05-09), nightly is cargo 1.54.0-nightly (rust-lang/cargo@070e459c2 2021-05-11), rustc 1.54.0-nightly (3e99439 2021-05-17).
The error occurs in a macro that generates a struct declaration with an implementation of a trait and calls another macro to take a string generated by another set of macros and put it into a doc attribute above the struct. Here are the lines containing the macro declarations.
The error looks like this:
error[E0658]: arbitrary expressions in key-value attributes are unstable
--> src/schemas.rs:152:13
|
152 | database_table_doc!($table_name $(, $page)?),
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
...
274 | / impl_row_from_sql! {
275 | | image
276 | | Image<'input> {
277 | | name: PageTitle,
... |
293 | | }
294 | | }
| |_- in this macro invocation
|
= note: see issue #78835 <https://github.com/rust-lang/rust/issues/78835> for more information
= help: add `#![feature(extended_key_value_attributes)]` to the crate attributes to enable
= note: this error originates in the macro `impl_row_from_sql` (in Nightly builds, run with -Z macro-backtrace for more info)
There are 22 calls to the macro, but only 13 errors, for the calls those whose contents start with $table_name:ident $output_type:ident<$life:lifetime>
. I tried to generate a minimal example by copying the macros and one of the failing calls, but failed: this reduced version compiled on both stable and nightly in the playground.
Somehow this sequence of tokens causes the error in the crate but not in the smaller playground example. I don't know much about the internals of the compiler here so have no idea how to change the playground example to generate the error.
Activity
hameerabbasi commentedon May 18, 2021
@rustbot ping cleanup
rustbot commentedon May 18, 2021
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good
"Cleanup ICE-breaking candidate". In case it's useful, here are some
instructions for tackling these sorts of bugs. Maybe take a look?
Thanks! <3
cc @AminArria @camelid @chrissimpkins @contrun @DutchGhost @elshize @h-michael @HallerPatrick @hdhoang @hellow554 @henryboisdequin @imtsuki @JamesPatrickGill @kanru @KarlK90 @LeSeulArtichaut @MAdrianMattocks @matheus-consoli @mental32 @nmccarty @Noah-Kennedy @pard68 @PeytonT @pierreN @Redblueflame @RobbieClarken @RobertoSnap @robjtede @SarthakSingh31 @shekohex @sinato @smmalis37 @steffahn @Stupremee @tamuhey @turboladen @woshilapin @yerke
hellow554 commentedon May 18, 2021
While compiling with nightly another (maybe (un-)related error) pops up, which isn't present on stable:Never mind, seems to be an issue with the 0.7.4 version of lexical-core.
cargo update
fixed that by updating to 0.7.6 and now I can see OPs errorhellow554 commentedon May 18, 2021
This code errors on nightly, but not on stable:
I had a similar piece of code (I try to post it in the next post) that fails with the exact message on stable as well.
But here's the regression:
searched nightlies: from nightly-2019-10-01 to nightly-2021-05-01
regressed nightly: nightly-2021-04-12
searched commits: from a836d9b to a866124
regressed commit: ba6275b
cc #82608 @Aaron1011
hellow554 commentedon May 18, 2021
This code fails on stable with the same message as on nightly:
I just "inlined" the
with_doc_comment
macro.So in 58d2bad the error message changed from
to
(that's what we have today)
cc #78837 #78835 @petrochenkov
I think the commit message makes it very clear why the possiblity was added to use macros there
What to do on this, is above my paygrade ;)
@rustbot modify labels: -E-needs-mcve
rustbot commentedon May 18, 2021
Error: Label ICEBreaker-Cleanup-Crew can only be set by Rust team members
Please let
@rust-lang/release
know if you're having trouble with this bot.hellow554 commentedon May 18, 2021
Funny enough, in the tracking issue #78835 @alexschrod had the same issue as in this post, so this error is somewhat known. In the paste crate it was reported at dtolnay/paste#29 and fixed in dtolnay/paste#30, so maybe that's something for you @Erutuon if you need a fix right now.
hameerabbasi commentedon May 18, 2021
@rustbot modify labels -E-needs-mcve
hameerabbasi commentedon May 18, 2021
Sorry for the spam!
@rustbot modify labels -ICEBreaker-Cleanup-Crew
3 remaining items
Erutuon commentedon May 18, 2021
@hellow554
Right, that's the reason for the
with_doc_comment
macro. On stable, taking a macro-generated string followed by an item and passing them to another macro and having that macro add the string to a doc attribute above the item seems to convince the compiler (somehow) that the doc attribute value is acceptable, even though it's not really a string literal.It looks like I'm using the same technique as the regression test, but on nightly now it doesn't compile in 13 out of the 22 macro calls in my code.
Aaron1011 commentedon May 18, 2021
This will be fixed by #85445
Fix incorrect gating of nonterminals in key-value attributes
hameerabbasi commentedon May 19, 2021
Assigning
P-critical
as discussed in the WG-prioritization discussion on Zulip and removing I-prioritize.@rustbot modify labels +P-critical -I-prioritize
Fix incorrect gating of nonterminals in key-value attributes
pietroalbini commentedon Jun 14, 2021
Fixed on 1.54 by #85445 and fixed on 1.53 by #86225.