The other cases: `concat_idents!`, `log_syntax!`, and `trace_macros!`,
(these macros, with `asm!`, are handled (eagerly) in feature_gate.rs).

just say "experimental."

See RFC 320, "Non-zeroing dynamic drops."

Fix #22173

[breaking-change]

Switch feature-gate checker from `box_syntax` to `box_patterns` when
visiting a pattern.

(Having to opt into both `box_syntax` and `box_patterns` seemed
unnecessary.)

[breaking-change]

    #[plugin] #[no_link] extern crate bleh;

becomes a crate attribute

    #![plugin(bleh)]

The feature gate is still required.

It's almost never correct to link a plugin into the resulting library /
executable, because it will bring all of libsyntax and librustc with it.
However if you really want this behavior, you can get it with a separate
`extern crate` item in addition to the `plugin` attribute.

Fixes #21043.
Fixes #20769.

[breaking-change]

Fixes #21833.

[breaking-change]

The 'stable_features' lint helps people progress from unstable to
stable Rust by telling them when they no longer need a `feature`
attribute because upstream Rust has declared it stable.

This compares to the existing 'unstable_features', which is used
to implement feature staging, and triggers on *any* use
of `#[feature]`.

The spelling corrections were made in both documentation comments and
regular comments.

Also some tidying up of a bunch of crate attributes

Does a sanity check of the version numbers.

I don't know if this handling of SIMD types is correct for the C ABI on
all platforms, so lets add an even finer feature gate than just the
`simd` one.

The `simd` one can be used with (relatively) little risk of complete
nonsense, the reason for it is that it is likely that things will
change. Using the types in FFI with an incorrect ABI will at best give
absolute nonsense results, but possibly cause serious breakage too, so
this is a step up in badness, hence a new feature gate.

These two attributes are used to change the entry point into a Rust program, but
for now they're being put behind feature gates until we have a chance to think
about them a little more. The #[start] attribute specifically may have its
signature changed.

This is a breaking change to due the usage of these attributes generating errors
by default now. If your crate is using these attributes, add this to your crate
root:

    #![feature(start)] // if you're using the #[start] attribute
    #![feature(main)]  // if you're using the #[main] attribute

cc #20064

To avoid using the feauture, change uses of `box <expr>` to
`Box::new(<expr>)` alternative, as noted by the feature gate message.

(Note that box patterns have no analogous trivial replacement, at
least not in general; you need to revise the code to do a partial
match, deref, and then the rest of the match.)

[breaking-change]

Conflicts:
	src/librbml/lib.rs
	src/libserialize/json_stage0.rs
	src/libserialize/serialize_stage0.rs
	src/libsyntax/ast.rs
	src/libsyntax/ext/deriving/generic/mod.rs
	src/libsyntax/parse/token.rs

parameters on impls must now also appear in the trait ref, self type,
or some associated type declared on the impl. This ensures that they
are constrianed in some way and that the semantics of the trait system
are well-defined (always a good thing).

There are three major ways to fix this error:

1. Convert the trait to use associated types; most often the type
   parameters are not constrained because they are in fact outputs of
   the impl.

2. Move the type parameters to methods.

3. Add an additional type parameter to the self type or trait so that
   the unused parameter can appear there.

In some cases, it is not possible to fix the impl because the trait
definition needs to be changed first (and that may be out of your
control). In that case, for the time being, you can opt out of these
rules by using `#[old_impl_check]` on the impl and adding a
`#![feature(old_impl_check)]` to your crate declaration.