…nough room

The current wording [seems to be confusing](https://www.reddit.com/r/rust/comments/5aat03/why_is_implementing_traits_on_primitive_types/). As an explanation when and why this could be considered as poor style would go beyond of the scope of this chapter I suggest to remove this remark.

Use where clasues and only where clauses for bounds in the
iterators for Graph.

The rest of the code uses bounds on the generic declarations for
Debug, and we may want to change those to for consistency. I did
not do that here because I don't know whether or not that's a good
idea. But for the iterators, they were inconsistent causing
confusion, at least for me.

Also used those general iterators in other methods.

`cargo new` now creates a `src/lib.rs` with a `tests` module by default. I've updated the earlier examples in this doc to reflect this. However, I don't know how we want to approach the "introduction" to idiomatic testing that follows in "the tests module" section. I _think_ it should be broken apart, with the module concept being introduced early on, and the `super` concept being addressed when we hit the `add_two` example. I'd like to get agreement on that being the right approach before I do it though.

I _also_ removed the `#fn main() {}` hidden at the beginning of each example, as these cause Rust Playground to not treat the file as a set of tests that it can run. Removing it _should_ cause Rust Playground to display a "Test >" button in the top left when a user runs the code, which will allow them to see the test runner output.

Fixes rust-lang#37655.

Part of rust-lang#34338

…sics

Part of rust-lang#34338

Part of rust-lang#34338

This allows the initial build of src/bootstrap itself to use a local
cargo taken from `configure --local-rust-root`.  It was already finding
rustc this way, but was always downloading cargo since it didn't know
where to find it.

It now matches the same logic that `config.rs` will use for stage0,
where both rustc and cargo are taken from `CFG_LOCAL_RUST_ROOT`.

…RMv5

Without these changes, play.rust-lang.org (as of today) would wrap
our examples in `fn main() {}`. This prevents the user from being able
to easily run the tests.

The narrative flows better if we follow what @steveklabnik is doing in
rust-lang/book#288. Therefore, I completely copied it.

I had used `/tmp/adder` for my previous commits. Flipped over to
`/home/you/projects/adder` for consistency with other parts of testing.md

Otherwise the optimizer can't be sure that pos <= cap. Added a paranoid debug_assert to ensure correctness instead.

Discussed in rust-lang#37546 the libs team reached the conclusion that a default zero
duration seems like a reasonable implementation of the `Default` trait.

Closes rust-lang#37546

Don't provide hint to add lifetime on impl items that implement a trait.

```rust
use std::str::FromStr;

pub struct Foo<'a> {
    field: &'a str,
}

impl<'a> FromStr for Foo<'a> {
    type Err = ();
    fn from_str(path: &str) -> Result<Self, ()> {
        Ok(Foo { field: path })
    }
}
```

would give the following hint:

```nocode
help: consider using an explicit lifetime parameter as shown: fn from_str(path: &'a str) -> Result<Self, ()>
  --> <anon>:9:5
   |
9  |     fn from_str(path: &str) -> Result<Self, ()> {
   |     ^
```

which is never correct, since then there will be a lifetime mismatch
between the impl and the trait.

Remove this hint for impl items that implement a trait.

While the commit message on this one sounds terrible, it's really not so
bad. The issue is that our test runner _expects_ a `fn main() {}` in
code blocks that it'll test, but this code really shouldn't have them.
If it did, then clicking the "play" link in the docs would result in
play.rust-lang.org not treating this code as a test example to be run.

This speeds up compilation of several rustc-benchmarks by 1--2% and the
workload in rust-lang#36799 by 5%.

As far as possible, use regular `default fn` specialization in favour of
ad-hoc conditionals.

…sized types

…ures::SmallVec.

This commit configures our `.travis.yml` to test the full suite of tests we have
on Buildbot right now. A whole mess of docker images are added to the `src/ci`
directory which represent all the build environments for each configuration.
Each of these environments is then configured in `.travis.yml` to run on the
auto branch.

Note that the full matrix of tests aren't intended to be run on all PRs.
Instead, we continue to run only one entry in the matrix, forcing all others to
finish quickly. Only the `auto` branch should run the full matrix of builds.

Also note that the infrastructure hasn't quite been allocated yet to the
rust-lang/rust repository, so everything is disabled for now except for the one
build that happens on PRs. Once that infrastructure is allocated though we can
enable this and let it fly!

Notable modifications from the current test suite today:

* Android tests are run in rustbuild instead of the makefiles, for whatever
  reason I couldn't get the makefiles to work on Travis.
* A debuginfo test was updated to work with the current version of the Android
  NDK.
* Some dependencies in `mk/tests.mk` were fixed to allow running tests in
  parallel.

This commit is an implementation of [RFC 1721] which adds a new target feature
to the compiler, `crt-static`, which can be used to select how the C runtime for
a target is linked. Most targets dynamically linke the C runtime by default with
the notable exception of some of the musl targets.

[RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md

This commit first adds the new target-feature, `crt-static`. If enabled, then
the `cfg(target_feature = "crt-static")` will be available. Targets like musl
will have this enabled by default. This feature can be controlled through the
standard target-feature interface, `-C target-feature=+crt-static` or
`-C target-feature=-crt-static`.

Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the
`crt-static` semantics we want with libc. The exact behavior of this attribute
is a little squishy, but it's intended to be a forever-unstable
implementation detail of the liblibc crate.

Specifically the `#[link(cfg(..))]` annotation means that the `#[link]`
directive is only active in a compilation unit if that `cfg` value is satisfied.
For example when compiling an rlib, these directives are just encoded and
ignored for dylibs, and all staticlibs are continued to be put into the rlib as
usual. When placing that rlib into a staticlib, executable, or dylib, however,
the `cfg` is evaluated *as if it were defined in the final artifact* and the
library is decided to be linked or not.

Essentially, what'll happen is:

* On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be
  linked to.
* On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be
  linked to.
* On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib
  are removed and `-lc` is passed instead.
* On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib
  are used and `-lc` is not passed.

This commit does **not** include an update to the liblibc module to implement
these changes. I plan to do that just after the 1.14.0 beta release is cut to
ensure we get ample time to test this feature.

cc rust-lang#37406

On cases of malformed format strings where a `{` hasn't been properly
escaped, like `println!("{");`, present a note explaining how to escape
the `{` char.

…ne, r=GuillaumeGomez

rustdoc: add line breaks to where clauses a la rustfmt

Much like my last PR for rustdoc (rust-lang#36679), this adds line breaks to certain statements based on their line length. Here the focus was on where clauses.

Some examples:
- [Where clause in a trait function](https://shiva.icesoldier.me/custom-std/std/iter/trait.Iterator.html?search=#method.unzip) (also in the trait header block at the top of the page)
- [Where clause on a bare function](https://shiva.icesoldier.me/doc-custom2/petgraph/visit/fn.depth_first_search.html)
- [Where clauses in trait impls on a struct](https://shiva.icesoldier.me/custom-std/std/collections/struct.HashMap.html) (scroll to the bottom) These are regularly not on their own line, but will be given their own line now if their "prefix text" doesn't give them enough room to sensibly print their constraints. HashMap's trait impls provide some examples of both behaviors.

The libstd links above are the whole docs rendered with this, and the "bare function" link above is in another set that pulls some notable crates together. `petgraph` was the one that brought this request up, and that collection also includes [itertools](https://shiva.icesoldier.me/doc-custom2/itertools/trait.Itertools.html) which provided an easy sample to test with.

r? @GuillaumeGomez

Update testing.md to reflect changes to cargo new

`cargo new` now creates a `src/lib.rs` with a `tests` module by default. I've updated the earlier examples in this doc to reflect this. However, I don't know how we want to approach the "introduction" to idiomatic testing that follows in "the tests module" section. I _think_ it should be broken apart, with the module concept being introduced early on, and the `super` concept being addressed when we hit the `add_two` example. I'd like to get agreement on that being the right approach before I do it though.

I _also_ removed the `#fn main() {}` hidden at the beginning of each example, as these cause Rust Playground to not treat the file as a set of tests that it can run. Removing it _should_ cause Rust Playground to display a "Test >" button in the top left when a user runs the code, which will allow them to see the test runner output.

…impl, r=eddyb

Don't provide hint to add lifetime on impl items

``` rust
use std::str::FromStr;

pub struct Foo<'a> {
    field: &'a str,
}

impl<'a> FromStr for Foo<'a> {
    type Err = ();
    fn from_str(path: &str) -> Result<Self, ()> {
        Ok(Foo { field: path })
    }
}
```

would give the following hint:

``` nocode
help: consider using an explicit lifetime parameter as shown: fn from_str(path: &'a str) -> Result<Self, ()>
  --> <anon>:9:5
   |
9  |     fn from_str(path: &str) -> Result<Self, ()> {
   |     ^
```

which is never correct, since then there will be a lifetime mismatch between the `impl` and the trait.

Remove this hint for all `impl` items.

Re: rust-lang#37363.

Remove remark about poor code style

The current wording [seems to be confusing](https://www.reddit.com/r/rust/comments/5aat03/why_is_implementing_traits_on_primitive_types/). As an explanation when and why this could be considered as poor style would go beyond of the scope of this chapter I suggest to remove this remark.

…or-error-impl, r=alexcrichton

Add Error implementation for std::sync::mpsc::RecvTimeoutError.

Fixes rust-lang#37525.

Graph Changes

General cleanup and adding a few methods that I want to use in Clippy.

Need somebody to bikeshed names.

rustc: Implement #[link(cfg(..))] and crt-static

This commit is an implementation of [RFC 1721] which adds a new target feature
to the compiler, `crt-static`, which can be used to select how the C runtime for
a target is linked. Most targets dynamically linke the C runtime by default with
the notable exception of some of the musl targets.

[RFC 1721]: https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md

This commit first adds the new target-feature, `crt-static`. If enabled, then
the `cfg(target_feature = "crt-static")` will be available. Targets like musl
will have this enabled by default. This feature can be controlled through the
standard target-feature interface, `-C target-feature=+crt-static` or
`-C target-feature=-crt-static`.

Next this adds an gated and unstable `#[link(cfg(..))]` feature to enable the
`crt-static` semantics we want with libc. The exact behavior of this attribute
is a little squishy, but it's intended to be a forever-unstable
implementation detail of the liblibc crate.

Specifically the `#[link(cfg(..))]` annotation means that the `#[link]`
directive is only active in a compilation unit if that `cfg` value is satisfied.
For example when compiling an rlib, these directives are just encoded and
ignored for dylibs, and all staticlibs are continued to be put into the rlib as
usual. When placing that rlib into a staticlib, executable, or dylib, however,
the `cfg` is evaluated *as if it were defined in the final artifact* and the
library is decided to be linked or not.

Essentially, what'll happen is:

* On MSVC with `-C target-feature=-crt-static`, the `msvcrt.lib` library will be
  linked to.
* On MSVC with `-C target-feature=+crt-static`, the `libcmt.lib` library will be
  linked to.
* On musl with `-C target-feature=-crt-static`, the object files in liblibc.rlib
  are removed and `-lc` is passed instead.
* On musl with `-C target-feature=+crt-static`, the object files in liblibc.rlib
  are used and `-lc` is not passed.

This commit does **not** include an update to the liblibc module to implement
these changes. I plan to do that just after the 1.14.0 beta release is cut to
ensure we get ample time to test this feature.

cc rust-lang#37406

…ddyb

Replace syntax's SmallVector with AccumulateVec

This adds a new type to data_structures, `SmallVec`, which wraps `AccumulateVec` with support for re-allocating onto the heap (`SmallVec::reserve`). `SmallVec` is then used to replace the implementation of `SmallVector` in libsyntax.

r? @eddyb

Fixes rust-lang#37371. Using `SmallVec` instead of libsyntax's `SmallVector` will provide the `N = 2/4` case easily (just needs a few more `Array` impls).

cc @nnethercote, probably interested in this area

Move all Linux/OSX CI infastructure to Travis

This commit configures our `.travis.yml` to test the full suite of tests we have
on Buildbot right now. A whole mess of docker images are added to the `src/ci`
directory which represent all the build environments for each configuration.
Each of these environments is then configured in `.travis.yml` to run on the
auto branch.

Note that the full matrix of tests aren't intended to be run on all PRs.
Instead, we continue to run only one entry in the matrix, forcing all others to
finish quickly. Only the `auto` branch should run the full matrix of builds.

Also note that the infrastructure hasn't quite been allocated yet to the
rust-lang/rust repository, so everything is disabled for now except for the one
build that happens on PRs. Once that infrastructure is allocated though we can
enable this and let it fly!

Notable modifications from the current test suite today:

* Android tests are run in rustbuild instead of the makefiles, for whatever
  reason I couldn't get the makefiles to work on Travis.
* A debuginfo test was updated to work with the current version of the Android
  NDK.
* Some dependencies in `mk/tests.mk` were fixed to allow running tests in
  parallel.

Add changelog for 1.13.0

The diagnostics PRs are excellent and some have excellent examples thanks @jonathandturner @estebank.

[Here are some notes about the performance changes during the release.
Compile times are improved %40 in some cases](https://gist.github.com/brson/1404c4bf4868d7d108f240a6ecba7f31).

This desires to be backported to beta for 1.13.

Sadly, the [1.12.1 changelog PR](rust-lang#37317) has not merged to master yet, and is sitting in a [rollup PR](rust-lang#37597).

r? @rust-lang/lang @rust-lang/compiler @rust-lang/libs @rust-lang/core

Add support for ARMv5TE architecture

…eddyb

introduce a `fudge_regions_if_ok` to address false region edges

Fixes rust-lang#37655.

r? @eddyb
cc @sfackler

Add documentation to some of the unstable intrinsics

Part of rust-lang#34338

Add missing urls for FusedIterator and TrustedLen traits

r? @steveklabnik

rustbuild: enable an initial local cargo

This allows the initial build of src/bootstrap itself to use a local
cargo taken from `configure --local-rust-root`.  It was already finding
rustc this way, but was always downloading cargo since it didn't know
where to find it.

It now matches the same logic that `config.rs` will use for stage0,
where both rustc and cargo are taken from `CFG_LOCAL_RUST_ROOT`.

[8/n] rustc: clean up lookup_item_type and remove TypeScheme.

_This is part of a series ([prev](rust-lang#37676) | [next]()) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https://github.com/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well.
If any motivation is unclear, please ask for additional PR description clarifications or code comments._

<hr>

* `tcx.tcache` -> `tcx.item_types`
* `TypeScheme` (grouping `Ty` and `ty::Generics`) is removed
* `tcx.item_types` entries no longer duplicated in `tcx.tables.node_types`
* `tcx.lookup_item_type(def_id).ty` -> `tcx.item_type(def_id)`
* `tcx.lookup_item_type(def_id).generics` -> `tcx.item_generics(def_id)`
* `tcx.lookup_generics(def_id)` -> `tcx.item_generics(def_id)`
* `tcx.lookup_{super_,}predicates(def_id)` -> `tcx.item_{super_,}predicates(def_id)`

rustbuild: support RelWithDebInfo for llvm

r? @alexcrichton

Balance the debug output of Lvalue Subslice

The current debug output for Lvalue Subslice is not balanced and does not respect the comment[1], which indicates that we use `slice[from:-to] in Python terms.`.  In python terms slices which have a start but no end are written as `a[start:]`, so following the comment, I fixed the output accordingly.

Grep-ing over the sources, I did not found any test cases checking this subslice debug output.
Note, I have not yet tested this change yet, as I am still waiting for the end of LLVM compilation.

[1] https://manishearth.github.io/rust-internals-docs/rustc/mir/enum.ProjectionElem.html

ICH: Add test case for call expressions.

r? @nikomatsakis

ICH: Add test case for if- and if-let-expressions.

r? @nikomatsakis

…chton

On fmt string with unescaped `{` note how to escape

On cases of malformed format strings where a `{` hasn't been properly escaped, like `println!("{");`, present a NOTE explaining how to escape the `{` char.

Fix rust-lang#34300.

Remove one bounds check from BufReader

Very minor thing. Otherwise the optimizer can't be sure that pos <= cap. Added a paranoid debug_assert to ensure correctness instead.

CC rust-lang#37573

Add missing urls for marker's traits

r? @steveklabnik

…r=brson

std: Derive `Default` for `Duration`.

Discussed in rust-lang#37546 the libs team reached the conclusion that a default zero
duration seems like a reasonable implementation of the `Default` trait.

Closes rust-lang#37546

Avoid unnecessary mk_ty calls in Ty::super_fold_with.

This speeds up compilation of several rustc-benchmarks by 1--2% and the workload in rust-lang#36799 by 5%.

r? @eddyb

change the `box_free` lang item to accept pointers to unsized types

in miri we use the `box_free` lang item as the destructor for `Box` objects, since the function's api matches that of an `fn drop(&mut self)` in a hypothetical `impl<T: ?Sized> Drop for Box<T>` exactly.

This works fine except if we insert a check in the `size_of` intrinsic to ensure that it is only called with sized types, since the `box_free` lang item calls that intrinsic.

cc @eddyb

no clue who to r? here, probably lang team?

…chton

vec: Write the .extend() specialization in cleaner style

As far as possible, use regular `default fn` specialization in favour of
ad-hoc conditionals.

No intentional functional change. Code quality was validated against the same
benchmarks that were used in initial trusted len development.

This change is prompted by taking impressions from
rust-lang#27749 (comment)

Mem urls

r? @steveklabnik

Bump verison to 1.15.0

The bootstrap compiler still needs to be updated, but that's waiting on new betas.