Skip to content

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

New issue

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

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

Already on GitHub? # to your account

Closed
pnkfelix opened this issue Apr 17, 2015 · 1 comment
Closed

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

pnkfelix opened this issue Apr 17, 2015 · 1 comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)

Comments

@pnkfelix
Copy link
Member

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.

@steveklabnik steveklabnik added the A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) label Apr 18, 2015
@brson
Copy link
Contributor

brson commented Dec 1, 2016

Doesn't seem actionable.

@brson brson closed this as completed Dec 1, 2016
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..)
Projects
None yet
Development

No branches or pull requests

3 participants