unbreak bitrig/openbsd build after 8389253d

`PathBuf::new` have been changed. Use `PathBuf::from` instead.

Apply the same change for freebsd too, while here.

Auto merge of #23681 - alexcrichton:rollup, r=alexcrichton

Test fixes and rebase conflicts, round 2

rollup merge of #23674: nagisa/fallout-1

Test fixes and rebase conflicts, round 1

Auto merge of #23546 - alexcrichton:hyphens, r=brson

The compiler will now issue a warning for crates that have syntax of the form
`extern crate "foo" as bar`, but it will still continue to accept this syntax.
Additionally, the string `foo-bar` will match the crate name `foo_bar` to assist
in the transition period as well.

This patch will land hopefully in tandem with a Cargo patch that will start
translating all crate names to have underscores instead of hyphens.

cc #23533

Fix some fallout in librustdoc

rollup merge of #23671: steveklabnik/doc_std_clone

rollup merge of #23638: pnkfelix/fsk-reject-specialized-drops

Reject specialized Drop impls.

See Issue #8142 for discussion.

This makes it illegal for a Drop impl to be more specialized than the original item.

So for example, all of the following are now rejected (when they would have been blindly accepted before):

```rust
struct S<A> { ... };
impl Drop for S<i8> { ... } // error: specialized to concrete type

struct T<'a> { ... };
impl Drop for T<'static> { ... } // error: specialized to concrete region

struct U<A> { ... };
impl<A:Clone> Drop for U<A> { ... } // error: added extra type requirement

struct V<'a,'b>;
impl<'a,'b:a> Drop for V<'a,'b> { ... } // error: added extra region requirement
```

Due to examples like the above, this is a [breaking-change].

(The fix is to either remove the specialization from the `Drop` impl, or to transcribe the requirements into the struct/enum definition; examples of both are shown in the PR's fixed to `libstd`.)

----

This is likely to be the last thing blocking the removal of the `#[unsafe_destructor]` attribute.

Fix #8142
Fix #23584

rollup merge of #23546: alexcrichton/hyphens

The compiler will now issue a warning for crates that have syntax of the form
`extern crate "foo" as bar`, but it will still continue to accept this syntax.
Additionally, the string `foo-bar` will match the crate name `foo_bar` to assist
in the transition period as well.

This patch will land hopefully in tandem with a Cargo patch that will start
translating all crate names to have underscores instead of hyphens.

cc #23533

rustc: Add support for `extern crate foo as bar`

The compiler will now issue a warning for crates that have syntax of the form
`extern crate "foo" as bar`, but it will still continue to accept this syntax.
Additionally, the string `foo-bar` will match the crate name `foo_bar` to assist
in the transition period as well.

This patch will land hopefully in tandem with a Cargo patch that will start
translating all crate names to have underscores instead of hyphens.

cc #23533

rollup merge of #23668: alexcrichton/io-zero

This commit alters the behavior of the `Read::read_to_end()` method to zero all
memory instead of passing an uninitialized buffer to `read`. This change is
motivated by the [discussion on the internals forum][discuss] where the
conclusion has been that the standard library will not expose uninitialized
memory.

[discuss]: http://internals.rust-lang.org/t/uninitialized-memory/1652

Closes #20314

rollup merge of #23662: steveklabnik/gh23421

I assume since both shifts say the same thing, I should fix both of them, but then I realized I don't strictly know about left shift.

Fixes #23421

r? @pnkfelix

rollup merge of #23661: steveklabnik/any_docs

http://www.reddit.com/r/rust/comments/304q00/type_information_in_rust/cpp43lu

rollup merge of #23659: GBGamer/master

For other permissions beside USR permissions, we need these constants.

fixes #23658

rollup merge of #23646: steveklabnik/doc_file

This is pretty basic, but it's nice to have something.

r? @alexcrichton

rollup merge of #23630: nrc/coerce-tidy

See notes on the first commit

Closes #18601

r? @nikomatsakis

cc @eddyb

rollup merge of #23629: liammonahan/master

Found a small typo on the Rust book "ownership" page.

Best,
Liam

r? @steveklabnik

rollup merge of #23592: alexcrichton/tweak-at-exit

There have been some recent panics on the bots and this commit is an attempt to
appease them. Previously it was considered invalid to run `rt::at_exit` after
the handlers had already started running. Due to the multithreaded nature of
applications, however, it is not always possible to guarantee this. For example
[this program][ex] will show off the abort.

[ex]: https://gist.github.com/alexcrichton/56300b87af6fa554e52d

The semantics of the `rt::at_exit` function have been modified as such:

* It is now legal to call `rt::at_exit` at any time. The return value now
  indicates whether the closure was successfully registered or not. Callers must
  now decide what to do with this information.
* The `rt::at_exit` handlers will now be run for a fixed number of iterations.
  Common cases (such as the example shown) may end up registering a new handler
  while others are running perhaps once or twice, so this common condition is
  covered by re-running the handlers a fixed number of times, after which new
  registrations are forbidden.

Some usage of `rt::at_exit` was updated to handle these new semantics, but
deprecated or unstable libraries calling `rt::at_exit` were not updated.

rollup merge of #23573: steveklabnik/doc_associated_types

rollup merge of #23282: nikomatsakis/fn-trait-inheritance

The primary motivation here is to sidestep #19032 -- for a time, I thought that we should improve coherence or otherwise extend the language, but I now think that any such changes will require more time to bake. In the meantime, inheritance amongst the fn traits is both logically correct *and* a simple solution to that obstacle. This change introduces inheritance and modifies the compiler so that it can properly generate impls for closures and fns.

Things enabled by this PR (but not included in this PR):

1. An impl of `FnMut` for `&mut F` where `F : FnMut` (https://github.com/rust-lang/rust/issues/23015).
2. A better version of `Thunk` I've been calling `FnBox`.

I did not include either of these in the PR because:

1. Adding the impls in 1 currently induces a coherence conflict with the pattern trait. This is interesting and merits some discussion.
2. `FnBox` deserves to be a PR of its own.

The main downside to this design is (a) the need to write impls by hand; (b) the possibility of implementing `FnMut` with different semantics from `Fn`, etc. Point (a) is minor -- in particular, it does not affect normal closure usage -- and could be addressed in the future in many ways (better defaults; convenient macros; specialization; etc). Point (b) is unfortunate but "just a bug" from my POV, and certainly not unique to these traits (c.f. Copy/Clone, PartialEq/Eq, etc). (Until we lift the feature-gate on implementing the Fn traits, in any case, there is room to correct both of these if we find a nice way.)

Note that I believe this change is reversible in the future if we decide on another course of action, due to the feature gate on implementing the `Fn` traits, though I do not (currently) think we should reverse it.

Fixes #18835.

r? @nrc

Bug fixes

Unit tests for Issue 8142, collected into one file.

Reject specialized Drop impls.

See Issue 8142 for discussion.

This makes it illegal for a Drop impl to be more specialized than the
original item.

So for example, all of the following are now rejected (when they would
have been blindly accepted before):

```rust
struct S<A> { ... };
impl Drop for S<i8> { ... } // error: specialized to concrete type

struct T<'a> { ... };
impl Drop for T<'static> { ... } // error: specialized to concrete region

struct U<A> { ... };
impl<A:Clone> Drop for U<A> { ... } // error: added extra type requirement

struct V<'a,'b>;
impl<'a,'b:a> Drop for V<'a,'b> { ... } // error: added extra region requirement
```

Due to examples like the above, this is a [breaking-change].

(The fix is to either remove the specialization from the `Drop` impl,
or to transcribe the requirements into the struct/enum definition;
examples of both are shown in the PR's fixed to `libstd`.)

----

This is likely to be the last thing blocking the removal of the
`#[unsafe_destructor]` attribute.

Includes two new error codes for the new dropck check.

Update run-pass tests to accommodate new dropck pass.

Update tests and docs to reflect new destructor restriction.

----

Implementation notes:

We identify Drop impl specialization by not being as parametric as the
struct/enum definition via unification.

More specifically:

 1. Attempt unification of a skolemized instance of the struct/enum
    with an instance of the Drop impl's type expression where all of
    the impl's generics (i.e. the free variables of the type
    expression) have been replaced with unification variables.

 2. If unification fails, then reject Drop impl as specialized.

 3. If unification succeeds, check if any of the skolemized
    variables "leaked" into the constraint set for the inference
    context; if so, then reject Drop impl as specialized.

 4. Otherwise, unification succeeded without leaking skolemized
    variables: accept the Drop impl.

We identify whether a Drop impl is injecting new predicates by simply
looking whether the predicate, after an appropriate substitution,
appears on the struct/enum definition.

Added `T:Send` bound to `JoinGuard<T>` to avoid specialized `Drop` impl.

Added `T:Send` bound to `Queue<T>` to avoid specialized `Drop` impl.

Added `T:Send` bound to `Packet<T>` to avoid specialized `Drop` impl.

added `T:Send` bound to `Mutex<T>` to avoid specialized Drop impl.

Added `W: Writer` bound to `BufferedWriter<W>` to avoid specialized `Drop` impl.

Added `T:Send` bound to `Queue<T>` to avoid specialized Drop impl.

Added `Write` bounds to avoid a specialized Drop impl for `BufWriter`.

Added `T:Send` bound to `sync::mpsc::Receiver` and `sync::mpsc::Sender`.

This was necessary to avoid specialized `Drop` impls for the two structs.

Remove unnecessary bounds from Drop impl for `Arc` and `arc::Weak` and
one of the helper method impls.

Change lint names to plurals

Add tests

Remove the UnusedCasts lint

Minor refactoring in coercion.rs

Add trivial cast lints.

This permits all coercions to be performed in casts, but adds lints to warn in those cases.

Part of this patch moves cast checking to a later stage of type checking. We acquire obligations to check casts as part of type checking where we previously checked them. Once we have type checked a function or module, then we check any cast obligations which have been acquired. That means we have more type information available to check casts (this was crucial to making coercions work properly in place of some casts), but it means that casts cannot feed input into type inference.

[breaking change]

* Adds two new lints for trivial casts and trivial numeric casts, these are warn by default, but can cause errors if you build with warnings as errors. Previously, trivial numeric casts and casts to trait objects were allowed.
* The unused casts lint has gone.
* Interactions between casting and type inference have changed in subtle ways. Two ways this might manifest are:
- You may need to 'direct' casts more with extra type information, for example, in some cases where `foo as _ as T` succeeded, you may now need to specify the type for `_`
- Casts do not influence inference of integer types. E.g., the following used to type check:

```
let x = 42;
let y = &x as *const u32;
```

Because the cast would inform inference that `x` must have type `u32`. This no longer applies and the compiler will fallback to `i32` for `x` and thus there will be a type error in the cast. The solution is to add more type information:

```
let x: u32 = 42;
let y = &x as *const u32;
```

An example for clone

std: Zero memory when calling `read_to_end()`

This commit alters the behavior of the `Read::read_to_end()` method to zero all
memory instead of passing an uninitialized buffer to `read`. This change is
motivated by the [discussion on the internals forum][discuss] where the
conclusion has been that the standard library will not expose uninitialized
memory.

[discuss]: http://internals.rust-lang.org/t/uninitialized-memory/1652

Closes #20314

Auto merge of #23654 - alexcrichton:rollup, r=alexcrichton

Test fixes and rebase conflicts, round 4

correct reference wrt shifts

Fixes #23421

Clean up Any's title line

http://www.reddit.com/r/rust/comments/304q00/type_information_in_rust/cpp43lu

Add basic information about associated types

Merge remote-tracking branch 'origin/master' into rollup

Add Examples for File

This is pretty basic, but it's nice to have something.

Add the other S_I(RWX)(GRP/OTH) for posix `creat`

Test fixes and rebase conflicts, round 3

Improve the wording of the example section description on the ownership page
to make it more clear.

rollup merge of #23653: dhuseby/bitrig-stage0-c64d671

@alexcrichton this adds the latest Bitrig snapshot.  Please upload the corresponding snapshot: https://github.com/dhuseby/rust-cross-bitrig/blob/master/snapshots/rust-stage0-2015-03-17-c64d671-bitrig-x86_64-41de2c7a69a1ac648d3fa3b65e96a29bdc122163.tar.bz2

rollup merge of #23652: alexcrichton/stabilize-hasher-finish

This commit enables writing a stable implementation of the `Hasher` trait as
well as actually calculating the hash of a vlaue in a stable fashion. The
signature is stabilized as-is.

rollup merge of #23645: steveklabnik/gh23642

Fixes #23642

rollup merge of #23644: mbrubeck/doc-edit

PR #23104 moved `is_null` and `offset` to an inherent impl on the raw pointer type.

I'm not sure whether or how it's possible to link to docs for that impl.

r? @steveklabnik

rollup merge of #23509: aturon/stab-entry

This commit marks as `#[stable]` the `Entry` types for the maps provided
by `std`. The main reason these had been left unstable previously was
uncertainty about an eventual trait design, but several plausible
designs have been proposed that all work fine with the current type definitions.

r? @Gankro

Test fixes and rebase conflicts, round 2

Fallout from changing fn traits to use inheritance rather than bridge
impls. This is a [breaking-change] (for gated code) in that when you
implement `Fn` (`FnMut`) you must also implement `FnOnce`. This commit
demonstrates how to fix it.

adding lastest Bitrig snapshot by hand

Update docs for ptr module.

PR #23104 moved `is_null` and `offset` to an inherent impl on the raw pointer
type.

Stabilize Entry types

This commit marks as `#[stable]` the `Entry` types for the maps provided
by `std`. The main reason these had been left unstable previously was
uncertainty about an eventual trait design, but several plausible
designs have been proposed that all work fine with the current type definitions.

Auto merge of #23536 - pnkfelix:arith-oflo-shifts, r=nikomatsakis

overflow-checking for rhs of shift operators

Subtask of #22020 ([RFC 560](https://github.com/rust-lang/rfcs/blob/master/text/0560-integer-overflow.md))

rollup merge of #23506: alexcrichton/remove-some-deprecated-things

Conflicts:
src/test/run-pass/deprecated-no-split-stack.rs

rollup merge of #23503: alexcrichton/fix-ptr-docs

The method with which backwards compatibility was retained ended up leading to
documentation that rustdoc didn't handle well and largely ended up confusing.

rollup merge of #23484: alexcrichton/marker-trait-stable

This trait has proven quite useful when defining marker traits to avoid the
semi-confusing `PhantomFn` trait and it looks like it will continue to be a
useful tool for defining these traits.

Test fixes and rebase conflicts, round 1

rollup merge of #23383: alexcrichton/fs-create-dir-all

Conflicts:
src/libstd/fs/mod.rs

rollup merge of #23598: brson/gate

Conflicts:
src/compiletest/compiletest.rs
src/libcollections/lib.rs
src/librustc_back/lib.rs
src/libserialize/lib.rs
src/libstd/lib.rs
src/libtest/lib.rs
src/test/run-make/rustdoc-default-impl/foo.rs
src/test/run-pass/env-home-dir.rs

rollup merge of #23650: brson/32-bit-userspace

The variable '$SHELL' is not actually defined by 'sh'.

This makes Rust build correctly in popular Docker images.

rollup merge of #23648: steveklabnik/rollup

- Successful merges: #22954, #23119, #23509, #23561, #23590, #23607, #23608, #23618, #23622, #23639, #23641
- Failed merges: #23401

rollup merge of #23641: steveklabnik/gh23632

Fixes #23632

rollup merge of #23640: nagisa/thread-less-weak

This is more portable as far as linux is concerned.

rollup merge of #23639: steveklabnik/gh21305

Fixes #21305

Not sure if we should include more than this here, but it should be good to have at least this.

rollup merge of #23637: apasel422/iter

rollup merge of #23634: WiSaGaN/bugfix/fix_dead_link

rollup merge of #23633: tomjakubowski/rustdoc-array-prim

Previously, impls for `[T; n]` were collected in the same place as impls for `[T]` and `&[T]`. This splits them out into their own primitive page in both core and std.

rollup merge of #23631: andersk/minstack-dlsym

Linking `__pthread_get_minstack`, even weakly, was causing Debian’s `dpkg-shlibdeps` to detect an unnecessarily strict versioned dependency on libc6.

Closes #23628.

rollup merge of #23622: steveklabnik/gh23196

Fixes #23196

rollup merge of #23619: steveklabnik/gh23220

Fixes #23571

I _think_ this is better, but other suggestions welcome too.

rollup merge of #23618: steveklabnik/gh23571

Fixes #23571

rollup merge of #23615: steveklabnik/gh23540

Closes #23540

rollup merge of #23612: dotdash/closure_bloat

For the rust-call ABI, the last function argument is a tuple that gets
untupled for the actual call. For bare functions using this ABI, the
code has access to the tuple, so we need to tuple the arguments again.
But closures can't actually access the tuple. Their arguments map to the
elements in the tuple. So what we currently do is to tuple the arguments
and then immediately untuple them again, which is pretty useless and we
can just omit it.

rollup merge of #23608: nagisa/refine-cursor-docstring

r? @steveklabnik

rollup merge of #23607: mahkoh/cursor

Closes #23599

r? @alexcrichton

rollup merge of #23604: apasel422/btree

`btree_map::IntoIter` (and `btree_set::IntoIter`) remains, but it is a bit trickier.

rollup merge of #23601: nikomatsakis/by-value-index

This is a [breaking-change]. When indexing a generic map (hashmap, etc) using the `[]` operator, it is now necessary to borrow explicitly, so change `map[key]` to `map[&key]` (consistent with the `get` routine). However, indexing of string-valued maps with constant strings can now be written `map["abc"]`.

r? @japaric
cc @aturon @Gankro

rollup merge of #23590: FuGangqiang/attr

rollup merge of #23580: nikomatsakis/pattern-and-overflow

rollup merge of #23579: Ms2ger/thread_local-unsafe

Conflicts:
src/libstd/thread/local.rs

rollup merge of #23561: steveklabnik/gh23422

Fixes #23422

rollup merge of #23557: aturon/rfc-909

This commit implements [RFC 909](https://github.com/rust-lang/rfcs/pull/909):

The `std::thread_local` module is now deprecated, and its contents are
available directly in `std::thread` as `LocalKey`, `LocalKeyState`, and
`ScopedKey`.

The macros remain exactly as they were, which means little if any code
should break. Nevertheless, this is technically a:

[breaking-change]

Closes #23547

rollup merge of #23541: aturon/stab-error

This small commit stabilizes the `Error` trait as-is, except that `Send`
and `Debug` are added as constraints. The `Send` constraint is because
most uses of `Error` will be for trait objects, and by default we would
like these objects to be transferrable between threads. The `Debug`
constraint is to ensure that e.g. `Box<Error>` is `Debug`, and because
types that implement `Display` should certainly implement `Debug` in any case.

In the near future we expect to add `Any`-like downcasting features to
`Error`, but this is waiting on some additional
mechanisms (`Reflect`). It will be added before 1.0 via default methods.

[breaking-change]

r? @alexcrichton

Closes #21790

rollup merge of #23538: aturon/conversion

Conflicts:
src/librustc_back/rpath.rs

rollup merge of #23536: pnkfelix/arith-oflo-shifts

overflow-checking for rhs of shift operators

Subtask of #22020 ([RFC 560](https://github.com/rust-lang/rfcs/blob/master/text/0560-integer-overflow.md))

rollup merge of #23517: vhbit/ext-socket-options

Continuation of #23380 - added corresponding constants for Windows, Linux, *BSDs

r? @alexcrichton

Alex, can you also cc to a person who can check correctness for Windows as I'm not that confident in header file I've downloaded.

rollup merge of #23515: nikomatsakis/issue-14985-trait-subtyping

Remove incorrect subtyping for `&mut Trait` and introduce coercion for `&mut (Trait+'a)` to `&mut (Trait+'b)` if `'a:'b`.

Fixes #14985.

r? @nrc

rollup merge of #23466: woehr/master

This fixes a bug in LLVM IR generation for in-line assembly where Rust would always use the host clobbers instead of target clobbers.

I also took this opportunity to clean/simplify the ```trans_inline_asm``` function.

This is my first Rust pull request; please let me know if I'm missing anything.

rollup merge of #23401: tshepang/crates-and-modules-doc-nits

Conflicts:
src/doc/trpl/crates-and-modules.md

rollup merge of #23283: brson/rpathfix

Fix regression in -C rpath that causes failures with symlinks

The new `relative_from` method no longer supports the case on unix
where both paths are absolute, which `-C rpath` depended on. This
version fixes the problem by copying the old path_relative_from
function into the rpath module.

Fixes #23140

After experimenting with the new `relative_from` function on `Path` I'm not sure what it's use case is. It no longer even figures out that the relative path from `/foo/bar` to `/foo/baz/qux` is `../baz/qux`.

rollup merge of #23269: shepmaster/split-not-double-ended

Closes #23262

rollup merge of #23211: FlaPer87/oibit-send-and-friends

Fixes #23225

r? @nikomatsakis