Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Procedural Macros expanding macros by example vs. __rust_unstable_column() #48781

Closed
llogiq opened this issue Mar 6, 2018 · 9 comments · Fixed by #63613
Closed

Procedural Macros expanding macros by example vs. __rust_unstable_column() #48781

llogiq opened this issue Mar 6, 2018 · 9 comments · Fixed by #63613
Labels
A-macros-2.0 Area: Declarative macros 2.0 (#39412) C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@llogiq
Copy link
Contributor

llogiq commented Mar 6, 2018

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).

@est31
Copy link
Member

est31 commented 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 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.

@est31
Copy link
Member

est31 commented Mar 6, 2018

Alternatively, you can try shadowing the __rust_unstable_column macro. As you are on nightly this should be no problem.

@llogiq
Copy link
Contributor Author

llogiq commented 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
Copy link
Member

est31 commented 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.

@pietroalbini pietroalbini added C-enhancement Category: An issue proposing an enhancement or a PR with one. A-macros-2.0 Area: Declarative macros 2.0 (#39412) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 6, 2018
@llogiq
Copy link
Contributor Author

llogiq commented 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
Copy link
Contributor Author

llogiq commented Mar 9, 2018

It appears RFC #2320 shows a way to resolve this.

@matklad
Copy link
Member

matklad commented May 17, 2019

Just a wild thought, but can we now use $crate::column! inside of libstd instead of __rust_unstable_column ?

@est31
Copy link
Member

est31 commented Jul 6, 2019

@matklad nice idea. It should work actually. You should try to make a PR and check whether the issue-43057.rs unit test breaks or not.

@petrochenkov
Copy link
Contributor

__rust_unstable_column is removed in #63613.

@bors bors closed this as completed in cd21715 Aug 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros-2.0 Area: Declarative macros 2.0 (#39412) C-enhancement Category: An issue proposing an enhancement or a PR with one. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants