Repository navigation
Macro import/export #3114
Description
We need a way to export macros from modules and import them in other modules.
Currently we either prepend a string of macro definitions to every file, such as with debug!, error!, etc., or we just copy and paste the macros we need. This second approach leads to code duplication and lots of subtly different implementations.
As a temporary workaround, we could probably use include!.
Activity
eholk commentedon Aug 6, 2012
This would provide a nice solution for #2247 as well.
brson commentedon Aug 6, 2012
Wishfully putting this on the 0.4 milestone.
graydon commentedon Mar 25, 2013
non-critical for 0.6, de-milestoning
brson commentedon Apr 16, 2013
Nominating this for a milestone.
pnkfelix commentedon May 6, 2013
Does
include!actually even function as a work-around for this problem? My brief experiments with using that did not seem to bear fruit.isaacaggrey commentedon May 6, 2013
@pnkfelix - I can't recall why, but I had to wrap the
include!in a function -- see example use case in a bug I am working on #4219 (comment)pnkfelix commentedon May 6, 2013
@isaacaggrey but in that case the scope of the macro will be limited to that function, yes? (At least, that matches my intuition about the usual intentions for lexically-scoped macros.) So that seems like a problem.
isaacaggrey commentedon May 6, 2013
@pnkfelix IIUC you would think so, but it seems to not limit the macro's scope to the function. If you are trying to import macros from a separate file (in my case,
integer-templates.rs), then I can call the imported macros (in my case,int_template!) anywhere in the current file (even outside of the function).I would link to a gist, but my Rust build is currently not working.
pnkfelix commentedon May 7, 2013
Hmm, I see that this pattern certainly used to work in the code base, but we do not seem to use that pattern any more; @jbclements changed it in SHA: ca147a0
He replaced it with some
#[macro_escape]attribute. See also commit SHA: 08b6057 which has a log message that explains the new scoping rules for macros (and also #5120 )(Let me see if I can use that information to get include to work on macro definitions.)
pnkfelix commentedon May 7, 2013
Or rather, the whole point is to avoid using
includeand instead use the modules themselves. Which is the original point of this ticket anyway. :)isaacaggrey commentedon May 7, 2013
Thanks for the update, @pnkfelix . I hadn't followed the last couple months of macro changes and didn't even realize that hack didn't work anymore!
I suppose I have the same question/issue as you then now. :)
pcwalton commentedon May 16, 2013
I do not believe this is backwards incompatible.
graydon commentedon Jun 13, 2013
accepted for feature-complete milestone
pnkfelix commentedon Aug 14, 2013
visiting for triage, email 2013-08-05.
I've looked at this in the past. Its something I'd like to see happen, especially coming from my experience working with Racket. (I'm not sure how many of the lessons/caveats from the Scheme community carry over here, though ... it depends in part on whether Rust has an analogue to
let{,*,rec}-syntaxor not.)alexcrichton commentedon Nov 29, 2013
As pointed out in #10723, it may be possible to place
#[macro_escape]at the top of a crate to let all the macros get serialized to the crate metadata. This would remove any need for importing/exporting macros, although it's not as general of a solution as having ausestatement import a macro.pnkfelix commentedon Jan 16, 2014
Accepted for P-low.
sfackler commentedon Jan 25, 2014
This was done in #11151.
alexcrichton commentedon Jan 25, 2014
Hurray! nice work @sfackler!
Merge pull request rust-lang#3114 from matthiaskrgr/typos
Auto merge of rust-lang#3114 - RalfJung:fn-call-tests, r=RalfJung
Use `intrinsic_name` to get the intrinsic name (rust-lang#3114)
Merge rust-lang#3114