Conversation
|
r? @aturon (rust_highfive has picked a reviewer for you, use r? to override) |
|
Does any of this need |
|
@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. |
|
@nikomatsakis is going to review this. |
|
I'll start looking at this tonight. One quick note from looking at the migration guide - The behavior of Apologies if this was already discussed in the RFC, I didn't look at it too closely at the time. |
|
All the code looks good, though to @sfackler's point, there is supposed to be a method on the |
|
(r=me with that fixed, and a rebase) |
|
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. |
|
@sfackler I could vaguely imagine some syntax extension that |
|
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. |
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. |
|
Needs a rebase. f+. |
|
This may want to hold off on removing the |
|
I agree with @alexcrichton about feature gate and had planned to say the same thing. |
Correct, and that's a fair point about tuple structs. Still I think |
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 I talked to @cmr briefly and he seemed roughly agreed with this. |
|
Indeed. On Mon, Jan 5, 2015 at 12:53 PM, Keegan McAllister <notifications@github.com
|
The implementation of LetSyntaxTT was specialized to macro_rules! in various ways. This gets rid of the false generality and simplifies the code.
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.
|
Rebased here, testing now. |
|
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.
|
Pushed with a fix for the cross compilation issue in |
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
|
Landed in #20610 |
|
Merge commit: 7975fd9 |
Fixes #20008.
This is a [breaking-change]. I've written a guide to migrating your code.