rollup merge of #19626: bluss/string-extend-str

Strings iterate to both char and &str, so it is natural it can also be extended or collected from an iterator of &str.

Apart from the trait implementations, `Extend<char>` is updated to use the iterator size hint, and the test added tests both the char and the &str versions of Extend and FromIterator.

rollup merge of #19623: rustyrazorblade/patch-1

Docs said from_utf8 accepts a vector when it actually accepts an array of bytes.

rollup merge of #19622: steveklabnik/fix_ringbuf_doc

  https://botbot.me/mozilla/rust/2014-12-07/?msg=27003846&page=20

rollup merge of #19620: retep998/memorymap

rollup merge of #19616: steveklabnik/gh19556

Closes #19556.

rollup merge of #19615: steveklabnik/gh19595

Fixes #19595.

rollup merge of #19614: steveklabnik/gh19599

Fixes #19599

rollup merge of #19608: jbranchaud/add-missing-semicolon-in-intro

rollup merge of #19604: vadimcn/gcc-less

- Support gcc-less installation on Windows.  To do so in unattended mode run:`<intaller>.exe /TYPE=compact /SILENT`.
- Do not require admin privileges to install.

cc #19519

rollup merge of #19598: japaric/ord

cc #18755

r? @alexcrichton
cc @bjz

rollup merge of #19594: Arcterus/master

It is useful to have configurable newlines in base64 as the standard
leaves that for the implementation to decide.  GNU `base64` apparently
uses LF, which meant in `uutils` we had to manually convert the CRLF to
LF.  This made the program very slow for large inputs.

[breaking-change]

rollup merge of #19592: jbranchaud/add-btreemap-iter-doctest

I'm interested in including doctests for `BTreeMap`'s `iter_mut` and `into_iter` methods in this PR as well, but I am not sure of the best way to demonstrate/test what they do for the doctests.

rollup merge of #19589: huonw/unboxed-closure-elision

This means that `Fn(&A) -> (&B, &C)` is equivalent to `for<'a> Fn(&'a A)
-> (&'a B, &'a C)` similar to the lifetime elision of lower-case `fn` in
types and declarations.

Closes #18992.

rollup merge of #19588: nodakai/libstd-fix-zombie-children-finder

Reported as a part of rust-lang/rust#19120

The logic of rust-lang/rust@74fb798a200dc82cf5b4a18065e3ea565229adc3 was
flawed because when a CI tool run the test parallely with other tasks,
they all belong to a single session family and the test may pick up
irrelevant zombie processes before they are reaped by the CI tool
depending on timing.

rollup merge of #19587: huonw/closure-feature-gate

detect UFCS drop and allow UFCS methods to have explicit type parameters.

Work towards #18875.

Since code could previously call the methods & implement the traits
manually, this is a

[breaking-change]

Closes #19586. Closes #19375.

rollup merge of #19585: mdinger/guide_typo

@steveklabnik r?

rollup merge of #19584: CaptainHayashi/patch-1

Substitutes 'lifetime' for 'liftime' in a few places.

Apologies if this has already been noticed/PRQed!  I did try to do due diligence, though :grinning:

rollup merge of #19581: luqmana/duc

Fixes #19575.

rollup merge of #19577: aidancully/master

pthread_key_create can be 0.
addresses issue #19567.

rollup merge of #19576: nhoss2/master

There was a link to a non existing guide

serialize: base64: remove some .as_bytes() from the tests

serialize: base64: improve newline handling speed

serialize: base64: allow LF in addition to CRLF and optimize slightly

It is useful to have configurable newlines in base64 as the standard
leaves that for the implementation to decide.  GNU `base64` apparently
uses LF, which meant in `uutils` we had to manually convert the CRLF to
LF.  This made the program very slow for large inputs.

[breaking-change]

auto merge of #19466 : nikomatsakis/rust/recursion-limit, r=eddyb

This is particularly important for deeply nested types, which generate deeply nested impls. This is a fix for #19318. It's possible we could also improve this particular case not to increment the recursion count, but it's worth being able to adjust the recursion limit anyhow.

cc @jdm
r? @pcwalton

auto merge of #19249 : barosl/rust/json-type-safety, r=alexcrichton

This pull request tries to improve type safety of `serialize::json::Encoder`.

Looking at #18319, I decided to test some JSON implementations in other languages. The results are as follows:

* Encoding to JSON

| Language | 111111111111111111 | 1.0 |
| --- | --- | --- |
| JavaScript™ | "111111111111111100" | "1" |
| Python | "111111111111111111" | **"1.0"** |
| Go | "111111111111111111" | "1" |
| Haskell | "111111111111111111" | "1" |
| Rust | **"111111111111111104"** | "1" |

* Decoding from JSON

| Language | "1" | "1.0" | "1.6" |
| --- | --- | --- | --- |
| JavaScript™ | 1 (Number) | 1 (Number) | 1.6 (Number) |
| Python | 1 (int) | 1.0 (float) | 1.6 (float) |
| Go | **1 (float64)** | 1 (float64) | 1.6 (float64) |
| Go (expecting `int`) | 1 (int) | **error** | error |
| Haskell (with `:: Int`) | 1 (Int) | 1 (Int) | **2 (Int)** |
| Haskell (with `:: Double`) | 1.0 (Double) | 1.0 (Double) | 1.6 (Double) |
| Rust (with `::<int>`) | 1 (int) | 1 (Int) | **1 (Int)** |
| Rust (with `::<f64>`) | 1 (f64) | 1 (f64) | 1.6 (f64) |

* The tests on Haskell were done using the [json](http://hackage.haskell.org/package/json) package.
* The error message printed by Go was: `cannot unmarshal number 1.0 into Go value of type int`

As you see, there is no uniform behavior. Every implementation follows its own principle. So I think it is reasonable to find a desirable set of behaviors for Rust.

Firstly, every implementation except the one for JavaScript is capable of handling `i64` values. It is even practical, because [Twitter API uses an i64 number to represent a tweet ID](https://dev.twitter.com/overview/api/twitter-ids-json-and-snowflake), although it is recommended to use the string version of the ID.

Secondly, looking into the Go's behavior, implicit type conversion is not allowed in their decoder. If the user expects an integer value to follow, decoding a float value will raise an error. This behavior is desirable in Rust, because we are pleased to follow the principles of strong typing.

Thirdly, Python's JSON module forces a decimal point to be printed even if the fractional part does not exist. This eases the distinction of a float value from an integer value in JSON, because by the spec there is only one type to represent numbers, `Number`.

So, I suggest the following three breaking changes:

1. Remove float preprocessing in serialize::json::Encoder

 `serialize::json::Encoder` currently uses `f64` to emit any integral type. This is possibly due to the behavior of JavaScript, which uses `f64` to represent any numeric value.

 This leads to a problem that only the integers in the range of [-2^53+1, 2^53-1] can be encoded. Therefore, `i64` and `u64` cannot be used reliably in the current implementation.

 [RFC 7159](http://tools.ietf.org/html/rfc7159) suggests that good interoperability can be achieved if the range is respected by implementations. However, it also says that implementations are allowed to set the range of number accepted. And it seems that the JSON encoders outside of the JavaScript world usually make use of `i64` values.

 This commit removes the float preprocessing done in the `emit_*` methods. It also increases performance, because transforming `f64` into String costs more than that of an integral type.

 Fixes #18319

2. Do not coerce to integer when decoding a float value

 When an integral value is expected by the user but a fractional value is found, the current implementation uses `std::num::cast()` to coerce to an integer type, losing the fractional part. This behavior is not desirable because the number loses precision without notice.

 This commit makes it raise `ExpectedError` when such a situation arises.

3. Always use a decimal point when emitting a float value

 JSON doesn't distinguish between integer and float. They are just numbers. Also, in the current implementation, a fractional number without the fractional part is encoded without a decimal point.

 Thereforce, when the value is decoded, it is first rendered as `Json`, either `I64` or `U64`. This reduces type safety, because while the original intention was to cast the value to float, it can also be casted to integer.

 As a workaround of this problem, this commit makes the encoder always emit a decimal point even if it is not necessary. If the fractional part of a float number is zero, ".0" is padded to the end of the result.

auto merge of #19644 : pcwalton/rust/oibit3, r=nikomatsakis

Add some missing Copy implementations

auto merge of #19645 : alexcrichton/rust/old-snap, r=brson

The most recent snapshot was produced on OSX 10.8, but this segfaults on OSX
10.7 so we need to roll back one snapshot so we can start bootstrapping on 10.7
systems again.

cc #19643

Revert "Register new snapshots"

This reverts commit 9b443289cf32cbcff16768614340f0c844675340.

auto merge of #19456 : nikomatsakis/rust/reborrow-closure-arg, r=pnkfelix

Otherwise region inference can fail when closure arguments include `ref` bindings. Test case included in the PR.

Link regions in `ref` bindings from fn arguments.

Stop masking overflow and propagate it out more aggressively; also improve error reporting to suggest to user how to fix.

Kill dead code

Add ability to configure recursion limit.

Fixes #19318.

Add a feature opt `opt_out_copy` that allows people to revert to the older
behavior temporarily. This feature will eventually transition to REJECTED.

librustc: Make `Copy` opt-in.

This change makes the compiler no longer infer whether types (structures
and enumerations) implement the `Copy` trait (and thus are implicitly
copyable). Rather, you must implement `Copy` yourself via `impl Copy for
MyType {}`.

A new warning has been added, `missing_copy_implementations`, to warn
you if a non-generic public type has been added that could have
implemented `Copy` but didn't.

For convenience, you may *temporarily* opt out of this behavior by using
`#![feature(opt_out_copy)]`. Note though that this feature gate will never be
accepted and will be removed by the time that 1.0 is released, so you should
transition your code away from using it.

This breaks code like:

    #[deriving(Show)]
    struct Point2D {
        x: int,
        y: int,
    }

    fn main() {
        let mypoint = Point2D {
            x: 1,
            y: 1,
        };
        let otherpoint = mypoint;
        println!("{}{}", mypoint, otherpoint);
    }

Change this code to:

    #[deriving(Show)]
    struct Point2D {
        x: int,
        y: int,
    }

    impl Copy for Point2D {}

    fn main() {
        let mypoint = Point2D {
            x: 1,
            y: 1,
        };
        let otherpoint = mypoint;
        println!("{}{}", mypoint, otherpoint);
    }

This is the backwards-incompatible part of #13231.

Part of RFC #3.

[breaking-change]

auto merge of #19574 : erickt/rust/vec-reserve, r=alexcrichton

(I don't understand why this works, and so I don't quite trust this yet. I'm pushing it up to see if anyone else can replicate this performance increase)

Somehow llvm is able to optimize this version of Vec::reserve into dramatically faster than the old version. In micro-benchmarks this was 2-10 times faster. It also reduce my Rust compile time from 41 minutes to 27 minutes.

Closes #19281.

auto merge of #19306 : steveklabnik/rust/gh19269, r=nikomatsakis,brson

Fixes #19269.

/cc @thestinger @mahkoh @mitsuhiko

auto merge of #19560 : sfackler/rust/should-fail-reason, r=alexcrichton

The test harness will make sure that the panic message contains the
specified string. This is useful to help make `#[should_fail]` tests a
bit less brittle by decreasing the chance that the test isn't
"accidentally" passing due to a panic occurring earlier than expected.
The behavior is in some ways similar to JUnit's `expected` feature:
`@Test(expected=NullPointerException.class)`.

Without the message assertion, this test would pass even though it's not
actually reaching the intended part of the code:
```rust
#[test]
#[should_fail(message = "out of bounds")]
fn test_oob_array_access() {
    let idx: uint = from_str("13o").unwrap(); // oops, this will panic
    [1i32, 2, 3][idx];
}
```

libserialize: Prefer into_string() to to_string() wherever possible

Except for the example code!

libserialize: Code cleanup

libserialize: Always use a decimal point when emitting a float value

JSON doesn't distinguish between integer and float. They are just
numbers. Also, in the current implementation, a fractional number
without the fractional part is encoded without a decimal point.

Thereforce, when the value is decoded, it is first rendered as Json,
either I64 or U64. This reduces type safety, because while the original
intention was to cast the value to float, it can also be casted to
integer.

As a workaround of this problem, this commit makes the encoder always
emit a decimal point even if it is not necessary. If the fractional part
of a float number is zero, ".0" is padded to the end of the result.

[breaking-change]

auto merge of #19506 : eddyb/rust/fmt-polish, r=alexcrichton

libserialize: Do not coerce to integer when decoding a float value

When an integral value is expected by the user but a fractional value is
found, the current implementation uses std::num::cast() to coerce to an
integer type, losing the fractional part. This behavior is not desirable
because the number loses precision without notice.

This commit makes it raise ExpectedError when such a situation arises.

[breaking-change]

libserialize: Remove float preprocessing in serialize::json::Encoder

serialize::json::Encoder currently uses f64 to emit any integral type.
This is possibly due to the behavior of JavaScript, which uses f64 to
represent any numeric value.

This leads to a problem that only the integers in the range of [-2^53+1,
2^53-1] can be encoded. Therefore, i64 and u64 cannot be used reliably
in the current implementation.

RFC 7159 suggests that good interoperability can be achieved if the
range is respected by implementations. However, it also says that
implementations are allowed to set the range of number accepted. And it
seems that the JSON encoders outside of the JavaScript world usually
make use of i64 values.

This commit removes the float preprocessing done in the emit_* methods.
It also increases performance, because transforming f64 into String
costs more than that of an integral type.

Fixes #18319

[breaking-change]

test: adjust pretty/issue-4264 for formatting changes.

core: make the public fmt API completely safe.

core: remove the dead function fmt::argumentstr.

documentation incorrectly described from_utf8

Docs said from_utf8 accepts a vector when it actually accepts a slice of bytes.

auto merge of #19555 : jbranchaud/rust/add-doctests-for-key-values-of-btreemap, r=Gankro

auto merge of #19378 : japaric/rust/no-as-slice, r=alexcrichton

Now that we have an overloaded comparison (`==`) operator, and that `Vec`/`String` deref to `[T]`/`str` on method calls, many `as_slice()`/`as_mut_slice()`/`to_string()` calls have become redundant. This patch removes them. These were the most common patterns:

- `assert_eq(test_output.as_slice(), "ground truth")` -> `assert_eq(test_output, "ground truth")`
- `assert_eq(test_output, "ground truth".to_string())` -> `assert_eq(test_output, "ground truth")`
- `vec.as_mut_slice().sort()` -> `vec.sort()`
- `vec.as_slice().slice(from, to)` -> `vec.slice(from_to)`

---

Note that e.g. `a_string.push_str(b_string.as_slice())` has been left untouched in this PR, since we first need to settle down whether we want to favor the `&*b_string` or the `b_string[]` notation.

This is rebased on top of #19167

cc @alexcrichton @aturon

auto merge of #19561 : csouth3/rust/treeset-bitops, r=Gankro

Implement the `BitOr`, `BitAnd`, `BitXor`, and `Sub` traits from `std::ops` for TreeSet.  The behavior of these operator overloads is consistent with [RFC 235](https://github.com/rust-lang/rfcs/blob/master/text/0235-collections-conventions.md#combinations).

r? @Gankro

Mention expected in testing docs

string: Add test for FromIterator<&str> and Extend<&str>

string: Add test for FromIterator<char> and Extend<char>

syntax: use UFCS in the expansion of `#[deriving(Ord)]`

cc #18755

string: Implement FromIterator<&str> and Extend<&str> for String

&str is a "particle" of a string already, see the graphemes iterator,
so it seems natural that we should be able to use it with Extend.

string: Use the iterator size_hint() in .extend()

Remove mention of Dequeue in collections docs.

  https://botbot.me/mozilla/rust/2014-12-07/?msg=27003846&page=20

auto merge of #19548 : luqmana/rust/mfb, r=nikomatsakis

Fixes #19367.

Make MemoryMap use HANDLE on Windows.
Also fixes some conflicting module names.

Signed-off-by: Peter Atashian <retep998@gmail.com>

auto merge of #19539 : cmr/rust/18959, r=nikomatsakis

Closes #18959

Technically, this causes code that once compiled to no longer compile, but
that code probably never ran.

[breaking-change]

------------

Not quite sure the error message is good enough, I feel like it ought to tell you "because it inherits from non-object-safe trait Foo", so I've opened up a follow-up issue #19538

Fix syntax error on android tests

auto merge of #19522 : mukilan/rust/import-conflicts-item, r=cmr

Fixes #19498

Add enum namespacing to the Guide.

Closes #19556.

Correct the reference with regards to floats

Fixes #19595.

remove usage of notrust from the docs

Fixes #19599

auto merge of #19488 : jbranchaud/rust/add-btree-set-doctests, r=alexcrichton

There is already a test for `union` in the test namespace, but this commit adds a doctest that will appear in the rustdocs.

Someone on IRC said, *Write doctests!*, so here I am.

I am not sure this is the best way to demonstrate the behavior of the union function, so I am open to suggestions for improving this. If I am on the right track I'd be glad to include similar doctests for `intersection`, `difference`, etc.

libtime: remove unnecessary `to_string()` calls

libtest: remove unnecessary `to_string()` calls

libterm: remove unnecessary `to_string()` calls

libsyntax: remove unnecessary `to_string()` calls

libstd: remove unnecessary `to_string()` calls

libserialize: remove unnecessary `to_string()` calls

librustc_back: remove unnecessary `to_string()` calls

libgetopts: remove unnecessary `to_string()` calls

libcollections: remove unnecessary `to_string()` calls

libtest: remove unnecessary `as_mut_slice()` calls

libstd: remove unnecessary `as_mut_slice` calls

librustdoc: remove unnecessary `as_mut_slice` calls

librustc_trans: remove unnecessary `as_mut_slice` calls

librustc: remove unnecessary `as_mut_slice` calls

libcollections: remove unnecessary `as_mut_slice()` calls

libtest: remove unnecessary `as_slice()` calls

libterm: remove unnecessary `as_slice()` calls

libsyntax: remove unnecessary `as_slice()` calls

libstd: remove unnecessary `as_slice()` calls

auto merge of #19407 : frewsxcv/rust/rm-reexports, r=cmr

In regards to:

https://github.com/rust-lang/rust/issues/19253#issuecomment-64836729

This commit:

* Changes the #deriving code so that it generates code that utilizes fewer
  reexports (in particur Option::\*, Result::\*, and Ordering::\*), which is necessary to
  remove those reexports in the future
* Changes other areas of the codebase so that fewer reexports are utilized

Add compile-fail tests for #19498

libserialize: remove unnecessary `as_slice()` calls

librustdoc: remove unnecessary `as_slice()` calls

librustc_trans: remove unnecessary `as_slice` calls

librustc_back: remove unnecessary `as_slice()` calls

librustc: remove unnecessary `as_slice()` calls

libregex_macros: remove unnecessary `as_slice` calls

libregex: remove unnecessary `as_slice` calls

liblog: remove unnecessary `as_slice` calls

libgraphviz: remove unnecessary `as_slice()` calls

libgetops: remove unnecessary `as_slice()` calls

libfmt_macros: remove unnecessary `as_slice()` calls