r? @steveklabnik

This dates from the stone-ages. We always configure LLVM with all
supported targets.

- Successful merges: #30129, #30134, #30136, #30144, #30150, #30153, #30154
- Failed merges:

This dates from the stone-ages. We always configure LLVM with all
supported targets.

The text mentions ```return```, but what's actually happening is a ```panic!```.

I think this fixes #30137. I basically just repeated some details that were scattered around other places in this document, and emphasized that you probably don't want an `extern crate` or `mod` statement to end up inside a function.

The documentation shows this:

    [dependencies]

    rand="0.3.0"

and says it allows any version compatible with 0.3.0, but then it says, "If we wanted to use only 0.3.0 exactly, we could use `=0.3.0`." That is very easy to misunderstand, so hopefully this PR will help others not to be as confused as me. :-)

This PR replaces uses of int/uint in some doc examples in various crates.

random/secret guess -> secret number.

Fixes #29993.

Fixes #29993.

I think this fixes #30137. I basically just repeated some details that were scattered around other places in this document, and emphasized that you probably don't want an `extern crate` or `mod` statement to end up inside a function.

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. :))