Broken on BSD. #12460

There's a little more allocation here and there now since
from_utf8_owned can't be used with Vec.

Rust currently defaults to `RelocPIC` regardless. This patch adds a new
codegen option that allows choosing different relocation-model. The
available models are:

    - default (Use the target-specific default model)
    - static
    - pic
    - no-pic

For a more detailed information use `llc --help`

In summary these are some example transitions this change makes:

    'a ||       => ||: 'a
    proc:Send() => proc():Send

The intended syntax for closures is to put the lifetime bound not at the front
but rather in the list of bounds. Currently there is no official support in the
AST for bounds that are not 'static, so this case is currently specially handled
in the parser to desugar to what the AST is expecting. Additionally, this moves
the bounds on procedures to the correct position, which is after the argument
list.

The current grammar for closures and procedures is:

    procedure := 'proc' [ '<' lifetime-list '>' ] '(' arg-list ')'
                        [ ':' bound-list ] [ '->' type ]
    closure := [ 'unsafe' ] ['<' lifetime-list '>' ] '|' arg-list '|'
                        [ ':' bound-list ] [ '->' type ]
    lifetime-list := lifetime | lifetime ',' lifetime-list
    arg-list := ident ':' type | ident ':' type ',' arg-list
    bound-list := bound | bound '+' bound-list
    bound := path | lifetime

This does not currently handle the << ambiguity in `Option<<'a>||>`, I am
deferring that to a later patch. Additionally, this removes the support for the
obsolete syntaxes of ~fn and &fn.

Closes #10553
Closes #10767
Closes #11209
Closes #11210
Closes #11211

This was quite a curious bug on windows, and the details can be found in the
comment I added to src/librustc/back/link.rs

All it checks, unfortunately, is that you actually printed at least
two lines for crateA paths and at least one line for crateB paths.
But that's enough to capture the spirit of the bug, I think.  I did
not bother trying to verify that the paths themselves reflected where
the crates end up.

This pass is purely AST based, and by running it earlier we emit more
useful error messages, e.g. type inference fails in the case of `let r =
break;` with few constraints on `r`, but its more useful to be told that
the `break` is outside a loop (rather than a type error) when it is.

Closes #13292.

From the 0.10 changelog:
 * The inner attribute syntax has changed from `#[foo];` to `#![foo]`.

concat_idents! is not as useful as it could be, due to macros only being
allowed in limited places, and hygiene, so lets feature gate it until we
make a decision about it.

cc #13294

This fixes #13238. It avoids an infinite loop when compiling
the tests with `-g`. Without this change, the debuginfo on
`black_box` prevents the method from being inlined, which
allows llvm to convert `silent_recurse` into a tail-call. This
then loops forever instead of consuming all the stack like it
is supposed to. This patch forces inlining `black_box`, which
triggers the right error.

It's surprising that `RefCell::get()` is implicitly doing a clone
on a value. This patch removes it and replaces all users with
either `.borrow()` when we can autoderef, or `.borrow().clone()`
when we cannot.

This was missed when dropping the null-termination from our string
types. An explicit null byte can still be placed anywhere in a string if
desired, but there's no reason to stick one at the end of every string
constant.

This also changes some of the download links in the documentation
to 'nightly'.

1778b636 provided the guarantee of no
`exchange_free` calls for ~ZeroSizeType, so a sentinel can now be used
without overhead.

Closes #11998

Fixes #10474

This commit tightens up the restriction on types used to index slices to require
exactly `uint` indices. Previously any integral type was accepted, but this
leads to a few subtle problems:

  * 64-bit indices don't make much sense on 32-bit systems
  * Signed indices for slices used as negative indexing isn't implemented

This was discussed at the recent work week, and also has some discussion on
issue #10453.

Closes #10453

There are a few instances of them in tests which are using functions
from std etc. that still are using ~[].

The various ...Rng::new() methods can hit IO errors from the OSRng they use,
and it seems sensible to expose them at a higher level. Unfortunately, writing
e.g. `StdRng::new().unwrap()` gives a much poorer error message than if it
failed internally, but this is a problem with all `IoResult`s.

this is useful for macros like vec! which construct containers

This commit deals with the fallout of the previous change by making tuples
structs have public fields where necessary (now that the fields are private by
default).

This is a continuation of the work done in #13184 to make struct fields private
by default. This commit finishes RFC 4 by making all tuple structs have private
fields by default. Note that enum variants are not affected.

A tuple struct having a private field means that it cannot be matched on in a
pattern match (both refutable and irrefutable), and it also cannot have a value
specified to be constructed. Similarly to private fields, switching the type of
a private field in a tuple struct should be able to be done in a backwards
compatible way.

The one snag that I ran into which wasn't mentioned in the RFC is that this
commit also forbids taking the value of a tuple struct constructor. For example,
this code now fails to compile:

    mod a {
        pub struct A(int);
    }

    let a: fn(int) -> a::A = a::A; //~ ERROR: first field is private

Although no fields are bound in this example, it exposes implementation details
through the type itself. For this reason, taking the value of a struct
constructor with private fields is forbidden (outside the containing module).

RFC: 0004-private-fields