Macro reform #20482

kmcallister · 2015-01-03T19:15:10Z

Fixes #20008.

This is a [breaking-change]. I've written a guide to migrating your code.

rust-highfive · 2015-01-03T19:15:17Z

r? @aturon

(rust_highfive has picked a reviewer for you, use r? to override)

steveklabnik · 2015-01-03T19:18:58Z

Does any of this need [breaking-change]

kmcallister · 2015-01-03T19:22:41Z

@steveklabnik: Yeah, good point. Since things change a few times in the Git history, maybe I'll just tag the doc commit and provide a link to the migration guide.

kmcallister · 2015-01-03T23:19:23Z

@nikomatsakis is going to review this.

nikomatsakis · 2015-01-04T00:32:14Z

f? @sfackler @cmr

sfackler · 2015-01-04T02:26:49Z

I'll start looking at this tonight.

One quick note from looking at the migration guide - The behavior of #[plugin] runtime linking the crate by default seems wrong. It pulls in a huge runtime dependency (the entire compiler), and all syntax extension libraries I can think of off the top of my head have separate plugin and runtime crates. My gut feeling is that #[plugin] should only link to it as a plugin, and users could have a second un-annotated extern crate foo if they actually want to do link to it at runtime.

Apologies if this was already discussed in the RFC, I didn't look at it too closely at the time.

emberian · 2015-01-04T03:47:10Z

All the code looks good, though to @sfackler's point, there is supposed to be a method on the Registry(or, I would assume, a flag instead, per-syntax-extension) that determines whether the crate gets linked at runtime.

emberian · 2015-01-04T03:47:24Z

(r=me with that fixed, and a rebase)

sfackler · 2015-01-04T04:39:02Z

It's not totally clear to me when a syntax extension would ever want to get linked at runtime, unless we add some machinery to build two versions of the crate, one with the rustc dependency and plugin_registrar and the other without.

huonw · 2015-01-04T04:47:57Z

@sfackler I could vaguely imagine some syntax extension that extern crates another one and uses its functionality for something.

sfackler · 2015-01-04T04:50:03Z

But then you'd only be importing it at runtime, not compile time in the extension, right? In any case, it seems like it'd make more sense to have the 99.999% case (not wanting to link at runtime) to be "automatic", not the other way around.

kmcallister · 2015-01-04T19:54:11Z

there is supposed to be a method on the Registry(or, I would assume, a flag instead, per-syntax-extension) that determines whether the crate gets linked at runtime.

Yeah, this was the original plan, but it's a bit tricky to pull off. I'm going to work on that during the alpha period. Plugins aren't part of the stable language, so I don't think the issue is worth blocking this PR with only 5 days left before 1.0-alpha.

emberian · 2015-01-05T02:45:24Z

Needs a rebase. f+.

alexcrichton · 2015-01-05T07:21:55Z

This may want to hold off on removing the macro_rules feature gate until rust-lang/rfcs#550 is resolved.

nikomatsakis · 2015-01-05T09:26:30Z

I agree with @alexcrichton about feature gate and had planned to say the same thing.

kmcallister · 2015-01-05T17:49:32Z

It isn't required to use {...} with macros, right? (fwiw, tuple structs are declared with () and ;, so the existing usages were not so foreign.)

Correct, and that's a fair point about tuple structs. Still I think {...} is the best style default.

kmcallister · 2015-01-05T17:52:49Z

This may want to hold off on removing the macro_rules feature gate until rust-lang/rfcs#550 is resolved.

I think it's fine to un-gate now, because we are committing to ungating for 1.0-final. In fact it would be bad if alpha users get a warning: macros are experimental message, as it implies they won't be available in 1.0. rust-lang/rfcs#550 is an important issue for the long-term future-proofing of the language, but it's also something of a subtle detail that most users will never encounter during the alpha period.

I talked to @cmr briefly and he seemed roughly agreed with this.

emberian · 2015-01-05T18:00:00Z

Indeed.

On Mon, Jan 5, 2015 at 12:53 PM, Keegan McAllister <notifications@github.com

wrote:

This may want to hold off on removing the macro_rules feature gate until
rust-lang/rfcs#550 rust-lang/rfcs#550 is
resolved.

I think it's fine to un-gate now, because we are committing to ungating
for 1.0-final. In fact it would be bad if alpha users get a warning:
macros are experimental message, as it implies they won't be available in
1.0. rust-lang/rfcs#550 rust-lang/rfcs#550 is
an important issue for the long-term future-proofing of the language, but
it's also something of a subtle detail that most users will never encounter
during the alpha period.

I talked to @cmr https://github.com/cmr briefly and he seemed roughly
agreed with this.

—
Reply to this email directly or view it on GitHub
#20482 (comment).

http://octayn.net/

The implementation of LetSyntaxTT was specialized to macro_rules! in various ways. This gets rid of the false generality and simplifies the code.

Fixes rust-lang#17103.

Many of libstd's macros are now re-exported from libcore and libcollections. Their libstd definitions have moved to a macros_stage0 module and can disappear after the next snapshot. Where the two crates had already diverged, I took the libstd versions as they're generally newer and better-tested. See e.g. d3c831b, which was a fix to libstd's assert_eq!() that didn't make it into libcore's. Fixes rust-lang#16806.

In preparation for the rename.

In the future we want to support #[macro_use(foo, bar)] mod macros; but it's not an essential part of macro reform. Reserve the syntax for now.

Instead of copy-pasting the whole macro_rules! item from the original .rs file, we serialize a separate name, attributes list, and body, the latter as pretty-printed TTs. The compilation of macro_rules! macros is decoupled somewhat from the expansion of macros in item position. This filters out comments, and facilitates selective imports.

kmcallister · 2015-01-05T20:03:13Z

Rebased here, testing now.

kmcallister · 2015-01-06T00:13:19Z

Bisecting locally to find the Android build failure.

macro_rules! is like an item that defines a macro. Other items don't have a trailing semicolon, or use a paren-delimited body. If there's an argument for matching the invocation syntax, e.g. parentheses for an expr macro, then I think that applies more strongly to the *inner* delimiters on the LHS, wrapping the individual argument patterns.

kmcallister · 2015-01-06T02:53:03Z

Pushed with a fix for the cross compilation issue in creader: Load parts of plugin metadata on demand, which makes that patch smaller.

Conflicts: src/libflate/lib.rs src/libstd/lib.rs src/libstd/macros.rs src/libsyntax/feature_gate.rs src/libsyntax/parse/parser.rs src/libsyntax/show_span.rs src/test/auxiliary/macro_crate_test.rs src/test/compile-fail/lint-stability.rs src/test/run-pass/intrinsics-math.rs src/test/run-pass/tcp-connect-timeouts.rs

alexcrichton · 2015-01-06T15:16:49Z

Landed in #20610

alexcrichton · 2015-01-06T15:20:00Z

Merge commit: 7975fd9

rust-highfive assigned aturon Jan 3, 2015

nikomatsakis assigned nikomatsakis and unassigned aturon Jan 4, 2015

Keegan McAllister added 9 commits January 5, 2015 11:38

Don't test codegen-units errors on stage1 (c.f. rust-lang#20184)

d1cf1b1

Replace LetSyntaxTT with MacroRulesTT

5e5924b

The implementation of LetSyntaxTT was specialized to macro_rules! in various ways. This gets rid of the false generality and simplifies the code.

Add a special macro nonterminal $crate

ad7c647

Allow leading :: in use items

e2a9c04

Implement macro re-export

5382881

Fixes rust-lang#17103.

Remove unused if_ok! macro

1c2fddc

Stop using macro_escape as an inner attribute

fc58479

In preparation for the rename.

Rename macro_escape to macro_use

5bf385b

In the future we want to support #[macro_use(foo, bar)] mod macros; but it's not an essential part of macro reform. Reserve the syntax for now.

Keegan McAllister added 3 commits January 5, 2015 12:00

creader: Convert free functions to Env methods

5171b32

creader: Use a single struct

24aa7f0

kmcallister force-pushed the macro-reform branch from c590a84 to d633f87 Compare January 5, 2015 21:11

Keegan McAllister added 11 commits January 5, 2015 18:21

creader: Load parts of plugin metadata on demand

f314e2c

Replace #[phase] with #[plugin] / #[macro_use] / #[no_link]

60be2f5

Move #[macro_reexport] to extern crate

0816255

Allow selective macro import

aa69cbd

Reserve the keyword 'macro'

c9f0ff3

Pass the #[plugin(...)] meta item to the registrar

d0163d3

Un-gate macro_rules

c2e2697

Forbid '#[macro_use] extern crate' outside the crate root

bbbb85a

Add a test case for accidental macro re-export

34b995d

Update docs

78e841d

kmcallister force-pushed the macro-reform branch from d633f87 to 78e841d Compare January 6, 2015 02:52

Add missing #[no_link]

2167e5b

alexcrichton closed this Jan 6, 2015

alexcrichton mentioned this pull request Jan 8, 2015

Establish stabilization path for macro_rules feature #17895

Closed

Macro reform #20482

Macro reform #20482

Uh oh!

Conversation

kmcallister commented Jan 3, 2015

Uh oh!

rust-highfive commented Jan 3, 2015

Uh oh!

steveklabnik commented Jan 3, 2015

Uh oh!

kmcallister commented Jan 3, 2015

Uh oh!

kmcallister commented Jan 3, 2015

Uh oh!

nikomatsakis commented Jan 4, 2015

Uh oh!

sfackler commented Jan 4, 2015

Uh oh!

emberian commented Jan 4, 2015

Uh oh!

emberian commented Jan 4, 2015

Uh oh!

sfackler commented Jan 4, 2015

Uh oh!

huonw commented Jan 4, 2015

Uh oh!

sfackler commented Jan 4, 2015

Uh oh!

kmcallister commented Jan 4, 2015

Uh oh!

emberian commented Jan 5, 2015

Uh oh!

alexcrichton commented Jan 5, 2015

Uh oh!

nikomatsakis commented Jan 5, 2015

Uh oh!

kmcallister commented Jan 5, 2015

Uh oh!

kmcallister commented Jan 5, 2015

Uh oh!

emberian commented Jan 5, 2015

Uh oh!

kmcallister commented Jan 5, 2015

Uh oh!

kmcallister commented Jan 6, 2015

Uh oh!

kmcallister commented Jan 6, 2015

Uh oh!

alexcrichton commented Jan 6, 2015

Uh oh!

alexcrichton commented Jan 6, 2015

Uh oh!

Uh oh!