std: Stablize the macros module

[alexcrichton]

This commit performs a pass over the std::macros module, applying stability
attributes where necessary. In particular, this audits macros for patterns such
as:

• Standard use of forward-to-format-args via $($arg:tt)* (or +)
• Prevent macro-defined identifiers from leaking into expression arguments as
  hygiene is not perfectly implemented.
• Wherever possible, $crate is used now.

Specifically, the following actions were taken:

• The std::macros module itself is no longer public.
• The panic! macro is stable
• The assert! macro is stable
• The assert_eq! macro is stable
• The debug_assert! macro is stable
• The debug_assert_eq! macro is stable
• The unreachable! macro is stable after removing the extra forms to bring the
  definition in line with the unimplemented! macro.
• The try! macro is stable
• The vec! macro is stable

[alexcrichton]

r? @aturon

[rust-highfive]

r? @pcwalton

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

[aturon]

What's the rationale for dropping the functionality here, rather than beefing up unimplemented?

[alexcrichton]

I'd personally like to remove both of them as they're just longer versions of panic! in my mind, but failing that I'd rather stick to a more conservative approach where we don't just duplicate-panic-in-each-macro just yet.

[aturon]

This basically looks good to me, but we may want to get input from someone with deeper macros knowledge.

Also, are we 100% sure we want to stabilize vec!? It's probably so widely-used that we can't ever get rid of it...

[alexcrichton]

With regard to vec!, you're thinking of perhaps a more generic collections-creating macro? The current implementation is pretty super-specialized to Vec (deconstructing Box<[T]> and reassembling), but it is unfortunate that we don't have macros for other containers. Furthermore, it'd be unfortunate to have either:

• A generic macro for all containers, plus a more efficient vec! macro
• A macro-per-container

I do agree though that we've put ourselves in a corner with vec! right now, we don't really have a great way out of it :(

cc @kmcallister, @sfackler

[sfackler]

If this is being removed, shouldn't the ext::bytes module be removed as well?

[alexcrichton]

Aha, indeed!

[sfackler]

The commit should be tagged as a [breaking-change] since fmt!, include_bin! and bytes! are going away.

[aturon]

@alexcrichton Yep, those were pretty much exactly my thoughts. The only question is whether we want to fully commit now, or wait till beta to admit that we have to.

[kmcallister]

I think the best case outcome for vec! is a generic macro that uses traits to work for multiple kinds of containers, at which point vec! could become a synonym.

[kmcallister]

These changes look good to me.

[alexcrichton]

rebased, re-r? @aturon