The docs currently define `array_expr`s as:
array_expr : '[' \"mut\" ? vec_elems? ']' ;
array_elems : [expr [',' expr]*] | [expr ',' \"..\" expr] ;
`vec_elems` is not defined anywhere else so it is probably a typo for `array_elems`.
This is a hack, but I don't think we can do much better as long as `derive` is
running at the syntax expansion phase.
If the custom_derive feature gate is enabled, this works with user-defined
traits and syntax extensions. Without the gate, you can't use e.g. #[derive_Clone]
directly, so this does not change the stable language.
This commit also cleans up the deriving code somewhat, and forbids some
previously-meaningless attribute syntax. For this reason it's technically a
[breaking-change]
Unstable items used in a macro expansion will now always trigger
stability warnings, *unless* the unstable items are directly inside a
macro marked with `#[allow_internal_unstable]`. IOW, the compiler warns
unless the span of the unstable item is a subspan of the definition of a
macro marked with that attribute.
E.g.
#[allow_internal_unstable]
macro_rules! foo {
($e: expr) => {{
$e;
unstable(); // no warning
only_called_by_foo!();
}}
}
macro_rules! only_called_by_foo {
() => { unstable() } // warning
}
foo!(unstable()) // warning
The unstable inside `foo` is fine, due to the attribute. But the
`unstable` inside `only_called_by_foo` is not, since that macro doesn't
have the attribute, and the `unstable` passed into `foo` is also not
fine since it isn't contained in the macro itself (that is, even though
it is only used directly in the macro).
In the process this makes the stability tracking much more precise,
e.g. previously `println!("{}", unstable())` got no warning, but now it
does. As such, this is a bug fix that may cause [breaking-change]s.
The attribute is definitely feature gated, since it explicitly allows
side-stepping the feature gating system.
The API this exposes is a little strange (being attached to `static`s),
so it makes sense to conservatively feature gate it. If it is highly
popular, it is possible to reverse this gating.
The Rust Reference should include the tuple indexing (using a number
as a field) notation; currently it is only available on
http://doc.rust-lang.org/std/primitive.tuple.html and not easily
searchable.
The Rust Reference should include the tuple indexing (using a number
as a field) notation; currently it is only available on
http://doc.rust-lang.org/std/primitive.tuple.html and not easily
searchable.
Added all active features to the list in reference.md.
Added a second note about keeping the reference.md list up-to-date to the bottom of the list, since not everyone (including me) reads the big comment at the top of it. :)
Ensured that the feature gate list in reference.md is kept in alphabetical order.
Added a second note about keeping the reference.md list up-to-date to
the bottom of the list, since not everyone (including me) reads the
big comment at the top of it. :)
Ensured that the feature gate list in reference.md is kept in
alphabetical order.
