You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Procedural Macros expanding macros by example vs. __rust_unstable_column() #48781
In flamer and overflower, I expand ExprMacs when I find them so I can fold their expansion. However, this clashes with current libstd implementation of assert!(..) etc., because they use the __rust_unstable_column() macro, which, it appears, may not be called from outside libstd. This causes an error when trying to apply the procedural macro.
In general: Is there a way to get the macro expanded version of the code within a procedural macro? Do I need to register differently?
(Note: Since this only occurs with procedural macros, this is nightly-only).
On the origins of why __rust_unstable_column!() exists: Once I've added column info to panic output and for this I was calling the column!() macro. But due to a gap in macros 1.0 hygiene this caused a regression (#43057). So we ended up adding and using the __rust_unstable_column!() macro instead.
I'm not very familiar with the capabilities of the procedural macro API but maybe you can just invoke the column!() macro instead of the __rust_unstable_column!() macro? It doesn't call the unstable column macro itself, but is rather built in, so it should work.
Honestly, I'd just like to use the expansion of the macro. Ideally the expander would deal with it, leaving me to care about my procedural macro. Shouldn't we fix this at the expander level instead of the caller?
IDK, I just want to avoid any kind of stabilisation of that macro which is a kludge and a hack but needed. Make sure it stays nightly only even if proc macros get stable.
Agreed, and that should be possible without requiring proc macro authors to resort to kludges of their own. We just need to figure out how to let them expand macros like rustc.
Activity
est31 commentedon Mar 6, 2018
On the origins of why
__rust_unstable_column!()exists: Once I've added column info to panic output and for this I was calling thecolumn!()macro. But due to a gap in macros 1.0 hygiene this caused a regression (#43057). So we ended up adding and using the__rust_unstable_column!()macro instead.I'm not very familiar with the capabilities of the procedural macro API but maybe you can just invoke the
column!()macro instead of the__rust_unstable_column!()macro? It doesn't call the unstable column macro itself, but is rather built in, so it should work.est31 commentedon Mar 6, 2018
Alternatively, you can try shadowing the
__rust_unstable_columnmacro. As you are on nightly this should be no problem.llogiq commentedon Mar 6, 2018
Honestly, I'd just like to use the expansion of the macro. Ideally the expander would deal with it, leaving me to care about my procedural macro. Shouldn't we fix this at the expander level instead of the caller?
est31 commentedon Mar 6, 2018
IDK, I just want to avoid any kind of stabilisation of that macro which is a kludge and a hack but needed. Make sure it stays nightly only even if proc macros get stable.
llogiq commentedon Mar 7, 2018
Agreed, and that should be possible without requiring proc macro authors to resort to kludges of their own. We just need to figure out how to let them expand macros like rustc.
llogiq commentedon Mar 9, 2018
It appears RFC #2320 shows a way to resolve this.
matklad commentedon May 17, 2019
Just a wild thought, but can we now use
$crate::column!inside of libstd instead of__rust_unstable_column?est31 commentedon Jul 6, 2019
@matklad nice idea. It should work actually. You should try to make a PR and check whether the
issue-43057.rsunit test breaks or not.petrochenkov commentedon Aug 15, 2019
__rust_unstable_columnis removed in #63613.Rollup merge of rust-lang#63613 - petrochenkov:stdhyg, r=alexcrichton