@@ -67,14 +67,14 @@ However, the exclamation point is really part of the invocation syntax, not the
67
67
name, and some syntax extensions are invoked with no exclamation point, for
68
68
example item decorators like ` deriving ` .
69
69
70
- We introduce an attribute ` use_macros ` to specify which macros from an external
70
+ We introduce an attribute ` macro_use ` to specify which macros from an external
71
71
crate should be imported to the syntax environment:
72
72
73
73
``` rust
74
- #[use_macros (vec, panic= " fail" )]
74
+ #[macro_use (vec, panic= " fail" )]
75
75
extern crate std;
76
76
77
- #[use_macros ]
77
+ #[macro_use ]
78
78
extern crate core;
79
79
```
80
80
@@ -97,17 +97,17 @@ hard error.
97
97
Many macros expand using other "helper macros" as an implementation detail.
98
98
For example, librustc's ` declare_lint! ` uses ` lint_initializer! ` . The client
99
99
should not know about this macro, although it still needs to be exported for
100
- cross-crate use. For this reason we allow ` #[use_macros ] ` on a macro
100
+ cross-crate use. For this reason we allow ` #[macro_use ] ` on a macro
101
101
definition.
102
102
103
103
``` rust
104
104
/// Not to be imported directly.
105
- #[export ]
105
+ #[macro_export ]
106
106
macro_rules! lint_initializer { ... }
107
107
108
108
/// Declare a lint.
109
- #[export ]
110
- #[use_macros (lint_initializer)]
109
+ #[macro_export ]
110
+ #[macro_use (lint_initializer)]
111
111
macro_rules! declare_lint {
112
112
($ name : ident , $ level : ident , $ desc : expr ) => (
113
113
static $ name : & 'static $ crate :: lint :: Lint
@@ -120,7 +120,7 @@ The macro `lint_initializer!`, imported from the same crate as `declare_lint!`,
120
120
will be visible only during further expansion of the result of invoking
121
121
` declare_lint! ` .
122
122
123
- ` use_macros ` on ` macro_rules ` is an optional part of this proposal that will be
123
+ ` macro_use ` on ` macro_rules ` is an optional part of this proposal that will be
124
124
implemented for 1.0 only if time permits. Without it, libraries that use
125
125
helper macros will need to list them in documentation so that users can import
126
126
them.
@@ -132,39 +132,42 @@ that's an unstable internal API, so it's outside the scope of this RFC.
132
132
133
133
We also clean up macro syntax in a way that complements the semantic changes above.
134
134
135
- ## ` #[use_macros (...)] mod `
135
+ ## ` #[macro_use (...)] mod `
136
136
137
- The ` use_macros ` attribute can be applied to a ` mod ` item as well. The
137
+ The ` macro_use ` attribute can be applied to a ` mod ` item as well. The
138
138
specified macros will "escape" the module and become visible throughout the
139
139
rest of the enclosing module, including any child modules. A crate might start
140
140
with
141
141
142
142
``` rust
143
- #[use_macros ]
143
+ #[macro_use ]
144
144
mod macros ;
145
145
```
146
146
147
147
to define some macros for use by the whole crate, without putting those
148
148
definitions in ` lib.rs ` .
149
149
150
- Note that ` #[use_macros ] ` (without a list of names) is equivalent to the
150
+ Note that ` #[macro_use ] ` (without a list of names) is equivalent to the
151
151
current ` #[macro_escape] ` . However, the new convention is to use an outer
152
152
attribute, in the file whose syntax environment is affected, rather than an
153
153
inner attribute in the file defining the macros.
154
154
155
155
## Macro export and re-export
156
156
157
- A macro definition qualified by ` #[export] ` becomes available to other crates.
158
- That is, it can be the target of ` #[use_macros] ` . Or put another way,
159
- ` #[export] macro_rules! ` works the way ` #[macro_export] macro_rules! ` does
160
- today. Adding ` #[export] ` has no effect on the syntax environment for the
161
- current crate.
157
+ Currently in Rust, a macro definition qualified by ` #[macro_export] ` becomes
158
+ available to other crates. We keep this behavior in the new system. A macro
159
+ qualified by ` #[macro_export] ` can be the target of ` #[macro_use(...)] ` , and
160
+ will be imported automatically when ` #[macro_use] ` is given with no list of
161
+ names.
162
+
163
+ ` #[macro_export] ` has no effect on the syntax environment for the current
164
+ crate.
162
165
163
166
We can also re-export macros that were imported from another crate. For
164
167
example, libcollections defines a ` vec! ` macro, which would now look like:
165
168
166
169
``` rust
167
- #[export ]
170
+ #[macro_export ]
168
171
macro_rules! vec {
169
172
($ ($ e : expr ),* ) => ({
170
173
let mut _temp = $ crate :: vec :: Vec :: new ();
@@ -178,7 +181,7 @@ Currently, libstd duplicates this macro in its own `macros.rs`. Now it could
178
181
do
179
182
180
183
``` rust
181
- #[reexport_macros (vec)]
184
+ #[macro_reexport (vec)]
182
185
extern crate collections;
183
186
```
184
187
@@ -271,9 +274,9 @@ reform. Two ways this could work out:
271
274
272
275
# Unresolved questions
273
276
274
- Should we forbid ` $crate ` in non-` #[export] ` ed macros? It seems useless,
275
- however I think we should allow it anyway, to encourage the habit of writing
276
- ` $crate:: ` for any references to the local crate.
277
+ Should we forbid ` $crate ` in non-exported macros? It seems useless, however I
278
+ think we should allow it anyway, to encourage the habit of writing ` $crate:: `
279
+ for any references to the local crate.
277
280
278
281
# Acknowledgements
279
282
0 commit comments