Fixes #29993.

The Rust build scripts do work if the source directory contains spaces. I tried to make it work with spaces. I managed to get the Rust's and LLVM's configure scripts to work with spaces in the path, but I could not figure out how to get the Rust makefiles working.

So for now, this PR updates Rust's `configure` to abort if the source path contains spaces. I also added a note about spaces in the source path to the README.

I think this should close #18477 for now.

This PR allows the constant evaluation of index operations on constant arrays and repeat expressions. This allows index expressions to appear in the expression path of the length expression of a repeat expression or an array type.

An example is

```rust
const ARR: [usize; 5] = [1, 2, 3, 4, 5];
const ARR2: [usize; ARR[1]] = [42, 99];
```

In most other locations llvm's const evaluator figures it out already. This is not specific to index expressions and could be remedied in the future.

* `const`: Add reference to raw pointers
* Change `expr!(...)` etc. examples to use `ident` instead.
  *Technically*, it should be `pat`, but that's not how it works in
  practice.
* `|`: add reference to closure syntax.
* Closure syntax entry.
* Indexing and slicing entries.
* Add history of obsolete and deprecated syntax.

r? @steveklabnik

Part of #29376

Part of #29376

This PR adds some safety checks to interning things in `ty::ctxt`. Accidentally re-interning an `AdtDef` has bitten me in the behind just last week (it messes up things in very subtle way only showing up later as an LLVM assertion).

Initially I had also added a check to `ty::ctxt::node_type_insert()` -- but there it seems to be expected that the same table slot is written to multiple times.

Roll-up candidate.

* `const`: Add reference to raw pointers
* Change `expr!(...)` etc. examples to use `ident` instead.
  *Technically*, it should be `pat`, but that's not how it works in
  practice.
* `|`: add reference to closure syntax.
* Closure syntax entry.
* Indexing and slicing entries.

I believe that because Windows' unit of resolution is 100ns that this unit of
time will ensure that the assertions will hold true as it's representable in the
native format.

cc #29970

Fixes https://github.com/rust-lang/rust/pull/29383#issuecomment-160652130

r? @bluss

Part of #29338

Fixes #29993.

- Successful merges: #30108, #30114, #30115, #30119, #30120, #30122
- Failed merges:

In #29932, I moved the location of TRPL, but I missed making the changes
in mk/tests.mk. This led to #30088 landing with a broken example.

As such, #30113 will need to land before this.

Along with https://github.com/rust-lang/rust/pull/30121, this should fix the last fallout from https://github.com/rust-lang/rust/pull/29932

Part of #29376

Part of #29376

The `f` argument will reference the actual value in the `d` box, not the box in the `bar`'s stack frame.

I am just learning Rust, so I don't know how to explain this well, but just from `f`'s type it is clear that it will be a pointer to an `i32`, not a pointer to a pointer. Some `println!("{:p}", ...)`'s can easily confirm this.

I would actually suggest to remove/simplify this part of the example. This is a subtle issue that can easily confuse people at the early stages of familiarizing with the language. (As I got confused by it. :))

Part of #29376

Fixes #30073. The input to `cfg!` is a meta attribute, but not _any_ meta attribute (e.g. `cfg!(allow(dead_code))` doesn't compile). But the macro_rules syntax can't quite express this, so I added a note to the doc.

Part of #29338

In #29932, I moved the location of TRPL, but I missed making the changes
in mk/tests.mk. This led to #30088 landing with a broken example.

As such, #30113 will need to land before this.

Part of #29376

I believe that because Windows' unit of resolution is 100ns that this unit of
time will ensure that the assertions will hold true as it's representable in the
native format.

cc #29970

Sorry, thanks to @Ms2ger for pointing this out in https://github.com/rust-lang/rust/pull/30088#discussion_r46142903

Thanks @Manishearth

The `f` argument will reference the actual value in the `d` box, not the
box in the `bar`'s stack frame.

This is done mostly so that we can refer to MIR types in csearch and other metadata related area.

Heads up, @rust-lang/compiler!

r? @nikomatsakis

r? @Manishearth

cc @huonw

This is done mostly so that we can refer to MIR types in csearch and other metadata related area.