Skip to content

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

Closed

Description

@llogiq

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

Activity

  1. est31 commented on Mar 6, 2018

    @est31
    Member

    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.

  2. est31 commented on Mar 6, 2018

    @est31
    Member

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

  3. llogiq commented on Mar 6, 2018

    @llogiq
    ContributorAuthor

    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?

  4. est31 commented on Mar 6, 2018

    @est31
    Member

    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.

  5. added
    C-enhancementCategory: An issue proposing an enhancement or a PR with one.
    A-decl-macros-2-0Area: Declarative macros 2.0 (#39412)
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Mar 6, 2018
  6. llogiq commented on Mar 7, 2018

    @llogiq
    ContributorAuthor

    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.

  7. llogiq commented on Mar 9, 2018

    @llogiq
    ContributorAuthor

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

  8. matklad commented on May 17, 2019

    @matklad
    Contributor

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

  9. est31 commented on Jul 6, 2019

    @est31
    Member

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

  10. petrochenkov commented on Aug 15, 2019

    @petrochenkov
    Contributor

    __rust_unstable_column is removed in #63613.

  11. added a commit that references this issue on Aug 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-decl-macros-2-0Area: Declarative macros 2.0 (#39412)C-enhancementCategory: An issue proposing an enhancement or a PR with one.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions