Rollup merge of #47842 - Manishearth:dead-code, r=nagisa Remove dead code The Clone impl makes the lint ignore the type.

Rollup merge of #47829 - estebank:break-in-for, r=cramertj Suggest removing value from `break` when invalid When attempting to use `break` with a value in a type of loop where it'd be invalid (any non-`loop`), suggest using `break` on its own. Close #34359.

Document the size of bool

Include space in suggestion `mut` in bindings

Fix #46614.

Implement extensible syscall interface for wasm

Currently it's possible to run tests with the native wasm target, but it's not possible to tell whether they pass or to capture the output, because libstd throws away stdout, stderr and the exit code. While advanced libstd features should probably require more specific targets (eg. wasm-unknown-web) I think even the unknown target should at least support basic I/O.

Any solution is constrained by these factors:
- It must not be javascript specific
- There must not be too strong coupling between libstd and the host environment (because it's an "unknown" target)
- WebAssembly does not allow "optional" imports - all imports *must* be resolved.
- WebAssembly does not support calling the host environment through any channel *other* than imports.

The best solution I could find to these constraints was to give libstd a single required import, and implement a syscall-style interface through that import. Each syscall is designed such that a no-op implementation gives the most reasonable fallback behaviour. This means that the following import table would be perfectly valid:
```javascript
imports.env = { rust_wasm_syscall: function(index, data) {} }
```

Currently I have implemented these system calls:
- Read from stdin
- Write to stdout/stderr
- Set the exit code
- Get command line arguments
- Get environment variable
- Set environment variable
- Get time

It need not be extended beyond this set if being able to run tests for this target is the only goal.

edit:
As part of this PR I had to make a further change. Previously, the rust entry point would be automatically called when the webassembly module was instantiated. This was problematic because from the javascript side it was impossible to call exported functions, access program memory or get a reference to the instance.

To solve this, ~I changed the default behaviour to not automatically call the entry point, and added a crate-level attribute to regain the old behaviour. (`#![wasm_auto_run]`)~ I disabled this behaviour when building tests.

remove intercrate ambiguity hints

The scheme was causing overflows during coherence checking (e.g. #47139). This is sort of a temporary fix; the proper fix I think involves reworking trait selection in deeper ways.

cc @sgrif -- this *should* fix diesel

cc @qnighy -- I'd like to discuss you with alternative techniques for achieving the same end. =) Actually, it might be good to put some energy into refactoring traits first.

r? @EddyB

Add approximate suggestions for rustfix

This adds `span_approximate_suggestion()` that lets you emit a
suggestion marked as "non-machine applicable" in the JSON output. UI
users see no difference. This is for when rustc and clippy wish to
 emit suggestions which will make sense to the reader (e.g. they may
have placeholders like `<type>`) but are not source-applicable, so that
rustfix/etc can ignore these.

fixes #39254

Rollup of 16 pull requests

- Successful merges: #47838, #47840, #47844, #47874, #47875, #47876, #47884, #47886, #47889, #47890, #47891, #47795, #47677, #47893, #47895, #47552
- Failed merges:

Specialize StepBy::nth

This allows optimizations of implementations of the inner iterator's `.nth` method.

Fix ICE when reading non-UTF-8 input from stdin

Fixes #22387.

rustc: Move location of `codegen-backends` dir

Right now this directory is located under:

```
$sysroot/lib/rustlib/$target/lib/codegen-backends
```

but after seeing what we do in a few other places it seems that a more
appropriate location would be:

```
$sysroot/lib/rustlib/$target/codegen-backends
```

so this commit moves it!

Avoid underflow in render_source_line

While testing rust-lang/rust#47655 I was able to make the compiler panic when it's compiled with debug assertions:

```shell
> rustc /dev/null --crate-type proc-macro

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

note: rustc 1.25.0-dev running on x86_64-apple-darwin

note: run with `RUST_BACKTRACE=1` for a backtrace

thread 'rustc' panicked at 'attempt to subtract with overflow', librustc_errors/emitter.rs:287:49
```

Without debug assertions the following warning is emitted:

```shell
> rustc /dev/null --crate-type proc-macro

warning: unused variable: `registrar`
 --> /dev/null:0:1
  |
  |
  = note: #[warn(unused_variables)] on by default
  = note: to avoid this warning, consider using `_registrar` instead
```

The panic is due to the unused variable warning being spanned to `/dev/null:0:1`. When `render_source_line` subtracts 1 from the line number to look up the source line it panics due to underflow. Without debug assertions this would wrap and cause us to return a blank string instead.

Fix by explicitly testing for 0 and exiting early. I'm unsure how to automatically test this now that rust-lang/rust#46655 has been approved.

Right now this directory is located under:

  $sysroot/lib/rustlib/$target/lib/codegen-backends

but after seeing what we do in a few other places it seems that a more
appropriate location would be:

  $sysroot/lib/rustlib/$target/codegen-backends

so this commit moves it!

Adding ICH to the glossary.

Fixes #47782.

rustc_trans: keep LLVM types for trait objects anonymous.

Fixes #47638 by reverting the addition of readable LLVM trait object type names.
r? @nikomatsakis

[MSP430] Don't enable trap_unreachable option by default on msp.

Since MSP430 doesn't meaningfully support faulting on illegal
instructions, LLVM generates a call to abort() function instead
of a trap instruction. Such calls are 4 bytes long, and that is
too much overhead for such small target.

r? @alexcrichton

rustc: Add an option to default hidden visibility

This commit adds a new option to target specifictions to specify that symbols
should be "hidden" visibility by default in LLVM. While there are no existing
targets that take advantage of this the `wasm32-unknown-unknown` target will
soon start to use this visibility. The LLD linker currently interprets `hidden`
as "don't export this from the wasm module" which is what we want for 90% of our
functions. While the LLD linker does have a "export this symbol" argument which
is what we use for other linkers, it was also somewhat easier to do this change
instead which'll involve less arguments flying around. Additionally there's no
need for non-`hidden` visibility for most of our symbols!

This change should not immediately impact the wasm targets as-is, but rather
this is laying the foundations for soon integrating LLD as a linker for wasm
code.

rustc: Add some defines for LLVM 7 compat

I was testing out the tip support to see what's going on with wasm, and this was
I believe the only issue encountered with LLVM 7 support so far.

Ignore run-pass/sse2 when using system LLVM

This is a test of `target_feature`, which needs a rust-specific patch to
LLVM to add `MCSubtargetInfo::getFeatureTable()`.

Update associated constants error message

Fixes #47570.

rustc_trans: clobber $1 (aka $at) on mips

This copies what clang does. There is a long explanation as to why this is needed in the clang source (tools/clang/lib/Basic/Targets/Mips.h).

std: use more portable error number in from_raw_os_error docs

On MIPS, error number 98 is not `EADDRINUSE` (it is `EPROTOTYPE`). To fix the resulting test failure this causes, use a more portable error number in the example documentation. `EINVAL` shold be more reliable because it was defined in the original Unix as 22 so hopefully most derivatives have defined it the same way.

Fix regression: account for trait methods in arg count mismatch error

Fixed #47706 (https://github.com/rust-lang/rust/issues/47706#issuecomment-361161495)

Original PR #47747 missed methods on trait definitions.

This edit was done in GitHub. I think I got the signature of the variant right, going by the ICE debug output and the other cases above.

Marked Debug implementations for primitive types as #[inline]

Change for issue #47792.

use correct casing for rename suggestions

If the original name is uppercase, use camel case. Otherwise, use snake
case.

Highlight code on diagnostics when underlined

Highlight the label's span with the respective color:

<img width="692" alt="" src="https://user-images.githubusercontent.com/1606434/32411026-a1842482-c18d-11e7-9933-6510eefbad19.png">

Fix #42112.

Move Duration to libcore

Fixes #46520; should be merged after #46508.

Fixes #22387.

Since MSP430 doesn't meaningfully support faulting on illegal
instructions, LLVM generates a call to abort() function instead
of a trap instruction. Such calls are 4 bytes long, and that is
too much overhead for such small target.

This commit adds a new option to target specifictions to specify that symbols
should be "hidden" visibility by default in LLVM. While there are no existing
targets that take advantage of this the `wasm32-unknown-unknown` target will
soon start to use this visibility. The LLD linker currently interprets `hidden`
as "don't export this from the wasm module" which is what we want for 90% of our
functions. While the LLD linker does have a "export this symbol" argument which
is what we use for other linkers, it was also somewhat easier to do this change
instead which'll involve less arguments flying around. Additionally there's no
need for non-`hidden` visibility for most of our symbols!

This change should not immediately impact the wasm targets as-is, but rather
this is laying the foundations for soon integrating LLD as a linker for wasm
code.

I was testing out the tip support to see what's going on with wasm, and this was
I believe the only issue encountered with LLVM 7 support so far.