Skip to content

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

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

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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