Macro import/export #3114

Closed
eholk opened this Issue Aug 6, 2012 · 18 comments

Comments

Projects
None yet
8 participants
@eholk
Contributor

eholk commented Aug 6, 2012

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

@eholk

This comment has been minimized.

Show comment
Hide comment
@eholk

eholk Aug 6, 2012

Contributor

This would provide a nice solution for #2247 as well.

Contributor

eholk commented Aug 6, 2012

This would provide a nice solution for #2247 as well.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Aug 6, 2012

Contributor

Wishfully putting this on the 0.4 milestone.

Contributor

brson commented Aug 6, 2012

Wishfully putting this on the 0.4 milestone.

@graydon

This comment has been minimized.

Show comment
Hide comment
@graydon

graydon Mar 25, 2013

Contributor

non-critical for 0.6, de-milestoning

Contributor

graydon commented Mar 25, 2013

non-critical for 0.6, de-milestoning

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Apr 16, 2013

Contributor

Nominating this for a milestone.

Contributor

brson commented Apr 16, 2013

Nominating this for a milestone.

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix May 6, 2013

Member

Does include! actually even function as a work-around for this problem? My brief experiments with using that did not seem to bear fruit.

Member

pnkfelix commented 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

This comment has been minimized.

Show comment
Hide comment
@isaacaggrey

isaacaggrey 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 mozilla#4219 (comment)

@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 mozilla#4219 (comment)

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix May 6, 2013

Member

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

Member

pnkfelix commented 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

This comment has been minimized.

Show comment
Hide comment
@isaacaggrey

isaacaggrey 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 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

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix May 7, 2013

Member

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

Member

pnkfelix commented 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

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix May 7, 2013

Member

Or rather, the whole point is to avoid using include and instead use the modules themselves. Which is the original point of this ticket anyway. :)

Member

pnkfelix commented May 7, 2013

Or rather, the whole point is to avoid using include and instead use the modules themselves. Which is the original point of this ticket anyway. :)

@isaacaggrey

This comment has been minimized.

Show comment
Hide comment
@isaacaggrey

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

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

This comment has been minimized.

Show comment
Hide comment
@pcwalton

pcwalton May 16, 2013

Contributor

I do not believe this is backwards incompatible.

Contributor

pcwalton commented May 16, 2013

I do not believe this is backwards incompatible.

@graydon

This comment has been minimized.

Show comment
Hide comment
@graydon

graydon Jun 13, 2013

Contributor

accepted for feature-complete milestone

Contributor

graydon commented Jun 13, 2013

accepted for feature-complete milestone

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix Aug 14, 2013

Member

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}-syntax or not.)

Member

pnkfelix commented 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}-syntax or not.)

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Nov 29, 2013

Member

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 a use statement import a macro.

Member

alexcrichton commented 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 a use statement import a macro.

@pnkfelix

This comment has been minimized.

Show comment
Hide comment
@pnkfelix

pnkfelix Jan 16, 2014

Member

Accepted for P-low.

Member

pnkfelix commented Jan 16, 2014

Accepted for P-low.

@sfackler

This comment has been minimized.

Show comment
Hide comment
@sfackler

sfackler Jan 25, 2014

Member

This was done in #11151.

Member

sfackler commented Jan 25, 2014

This was done in #11151.

@alexcrichton

This comment has been minimized.

Show comment
Hide comment
@alexcrichton

alexcrichton Jan 25, 2014

Member

Hurray! nice work @sfackler!

Member

alexcrichton commented Jan 25, 2014

Hurray! nice work @sfackler!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment