1. this isn't actually true about diabetes
2. people with diabetes will get *real sad* when reading this
3. it isn't actually necessary.

I got a bit confused reading the guide over why all of a sudden there was an asterisk in the code. I was explained what it was there for in the IRC, and I think it should added it to the docs to prevent any further confusion!

This pull request implements the functionality for [RFC 873](https://github.com/rust-lang/rfcs/blob/master/text/0873-type-macros.md). This is currently just an update of @freebroccolo's branch from January, the corresponding commits are linked in each commit message.

@nikomatsakis and I had talked about updating the macro language to support a lifetime fragment specifier, and it is possible to do that work on this branch as well. If so we can (collectively) talk about it next week during the pre-RustCamp work week.

* Some clarifying rephrasing.
* Rename B.x back to B.a.
* Make null pointer optimization section bit more concrete.

r? @Gankro 

In Section 3.2, TARPL says that "standard allocators (including jemalloc, the one used by default in Rust) generally consider passing in 0 for the size of an allocation as Undefined Behaviour."
However, the C standard and jemalloc manual says allocating zero bytes
should succeed:

- C11 7.22.3 paragraph 1: "If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object."
- [jemalloc manual](http://www.freebsd.org/cgi/man.cgi?query=jemalloc&sektion=3): "The malloc and calloc functions return a	pointer	to the allocated memory if successful; otherwise a NULL pointer is returned and errno is set to ENOMEM."
    + Note that the description for `allocm` says "Behavior	is undefined if	size is 0," but it is an experimental API.

r? @Gankro 

The drop flags are Lvalue (and thus ByRef) datums that hold a u8 value,
so their value type should be u8, not a pointer to u8.

- Successful merges: #27546, #27550
- Failed merges: 

In Section 3.2, TARPL says that "standard allocators (including jemalloc, the one used by default in Rust) generally consider passing in 0 for the size of an allocation as Undefined Behaviour."
However, the C standard and jemalloc manual says allocating zero bytes
should succeed:

- C11 7.22.3 paragraph 1: "If the size of the space requested is zero, the behavior is implementation-defined: either a null pointer is returned, or the behavior is as if the size were some nonzero value, except that the returned pointer shall not be used to access an object."
- [jemalloc manual](http://www.freebsd.org/cgi/man.cgi?query=jemalloc&sektion=3): "The malloc and calloc functions return a	pointer	to the allocated memory if successful; otherwise a NULL pointer is returned and errno is set to ENOMEM."
    + Note that the description for `allocm` says "Behavior	is undefined if	size is 0," but it is an experimental API.

Fixes #26115

* Some clarifying rephrasing.
* Rename B.x back to B.a.
* Make null pointer optimization section bit more concrete.

The drop flags are Lvalue (and thus ByRef) datums that hold a u8 value,
so their value type should be u8, not a pointer to u8.

r? @alexcrichton 

This permits collections with `String` keys to be ranged over with
`&str` bounds. The `K` defaults for `Min` and `Max` permit the default
type parameter fallback to work with things like

```rust
use std::collections::{BTreeSet, Bound};
let set = BTreeSet::<String>::new();
set.range(Bound::Included("a"), Bound::Unbounded);
```

Without the defaults, the type of the maximum bound would be
unconstrained.

r? @Gankro

These are for syntaxes that haven't existed for a long time.

- Successful merges: #27285, #27524, #27533, #27535, #27538, #27539
- Failed merges: 

This permits collections with `String` keys to be ranged over with
`&str` bounds. The `K` defaults for `Min` and `Max` permit the default
type parameter fallback to work with things like

```rust
use std::collections::{BTreeSet, Bound};
let set = BTreeSet::<String>::new();
set.range(Bound::Included("a"), Bound::Unbounded);
```

Without the defaults, the type of the maximum bound would be
unconstrained.

Fixes #26115

1. mention them in the function chapter
2. mention their coercion to closures in the closures chapter

Fixes #26746

We haven't discussed this syntax yet, so provide a basic explanation
and link up to later chapters.

Fixes #26917

'work' can refer to the game itself, ie, 'this compiles but the game isn't finished,'
so 'compile' is a more clear way to describe the problem.

Thanks jhun on irc

This should be a bit more prominent.

Fixes #27109

This wording was too strong.

Fixes #27523

I also included some smaller trait-related changes.

Fixes #26991.

r? @shepmaster 
r? @steveklabnik 

… are not actually broken."

This reverts commit 354cf4b5.


Unfortunately these [tests are failing](http://buildbot.rust-lang.org/builders/nightly-dist-rustc-linux/builds/224/steps/distcheck/logs/stdio) on the snapshot/nightly bots with the [same message](https://gist.github.com/alexcrichton/611705ded07b0d73ded9) found in #27514

1. mention them in the function chapter
2. mention their coercion to closures in the closures chapter

Fixes #26746

This wording was too strong.

Fixes #27523

We haven't discussed this syntax yet, so provide a basic explanation
and link up to later chapters.

Fixes #26917

This should be a bit more prominent.

Fixes #27109

'work' can refer to the game itself, ie, 'this compiles but the game isn't finished,'
so 'compile' is a more clear way to describe the problem.

Thanks jhun on irc

This reverts commit 354cf4b5.

This changes the current behaviour for two cases (that I know of)
```rust
mod foo {
    extern crate bar;
}
// `bar::` changes to `foo::bar::`
```

```rust
extern crate bar as quux;
// `bar::` changes to `quux::`
```
For example:
```rust
mod foo {
    extern crate core;
}

fn assert_clone<T>() where T : Clone { }

fn main() {
    assert_clone::<foo::core::atomic::AtomicBool>();
    // error: the trait `core::clone::Clone` is not implemented for the type `core::atomic::AtomicBool` [E0277]
    // changes to
    // error: the trait `foo::core::clone::Clone` is not implemented for the type `foo::core::atomic::AtomicBool` [E0277]
}
```

Notably the following test case broke:
```rust
 #[bench]
 fn bar(x: isize) { }
 //~^ ERROR mismatched types
 //~| expected `fn(&mut test::Bencher)`
 // changed to
 //~| expected `fn(&mut __test::test::Bencher)`
```
If a crate is linked multiple times the path with the least segments is stored.
Partially addresses #1920. (this doesn't solve the issue raised about re-exports)

r? @nikomatsakis 

- Successful merges: #27519, #27521, #27525, #27527, #27528
- Failed merges: 

For #27471