Skip to content

difficulty: unstable helper macro used by stable macro_rules macro #24534

Closed
@pnkfelix

Description

@pnkfelix

Spawned off of #24370

As a strategy for statically checking the input to the panic! macro, I had its expansion include a helper procedural macro that did some inspection of the input.

The helper macro (named ensure_not_fmt_string_literal, though that really shouldn't matter) was supposed to be unstable. We don't have a direct way to mark such a macro as unstable though, since it ends up being exposed during the intermediate expansion of client code that invokes panic! (or assert!, etc).

Furthermore, some very clever hacks that @huonw came up with (and some not so clever hacks from me) all failed to enforce the desired instability guarantee.

  • On my end, I tried to have the macro conditionally expand into a reference to an unstable constant when called from somewhere other that panic!.
  • huon's idea was an improvement on this: Pass in a reference to an unstable type as part of the input to to macro, and enforce that it be unstable by binding it to a constant with the ascribed type. (Oh wait, maybe that last bit was what caused the resulting problem... described below)

In either case, making this yield instability required that ensure_not_fmt_string_literal not carry the #[allow_internal_unstable] attribute. But then removing that attribute caused its expansion into uses of format internals to fail. (This should not have been an issue, according to @huonw .)

So, at this point, I have decided to punt on solving this problem. Thus this ticket, which says: Let's fix this. Eventually. Maybe.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-macrosArea: All kinds of macros (custom derive, macro_rules!, proc macros, ..)

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions