…put.

Point at the immutable local variable when trying to modify one of its
fields.

Given a file:

```rust
struct Foo {
    pub v: Vec<String>
}

fn main() {
    let f = Foo { v: Vec::new() };
    f.v.push("cat".to_string());
}
```

present the following output:

```
error: cannot borrow immutable field `f.v` as mutable
 --> file.rs:7:13
  |
6 |    let f = Foo { v: Vec::new() };
  |        - this should be `mut`
7 |    f.v.push("cat".to_string());
  |    ^^^

error: aborting due to previous error
```

Change the wording of mutable borrow on immutable binding from "this
should be `mut`" to "consider changing this to `mut f`".

…uct field reordering.

…Item`.

See rust-lang/rfcs#1414.

Updates rust-lang#38865.

It does not seem valuable to always evaluate the right-hand side here.

Adds a test for issue rust-lang#31946 which was fixed a while ago.

Also update some 128 bit builtins to be panic-free without relying
on the const evaluator.

Now it always implies right-alignment, so that padding zeroes are placed after the sign (if any) and before the digits. In other words, it always takes precedence over explicitly specified `[[fill]align]`. This also affects the '#' flag: zeroes are placed after the prefix (0b, 0o, 0x) and before the digits.

           :05     :<05    :>05    :^05
before   |-0001| |-1000| |-0001| |-0100|
after    |-0001| |-0001| |-0001| |-0001|
          :#05x   :<#05x  :>#05x  :^#05x
before   |0x001| |0x100| |000x1| |0x010|
after    |0x001| |0x001| |0x001| |0x001|

Fixes rust-lang#39997 [breaking-change]

Now it always implies right-alignment, so that padding zeroes are placed after the sign (if any) and before the digits. In other words, it always takes precedence over explicitly specified `[[fill]align]`.

               :06      :<06     :>06     :^06
    before   |-001.2| |-1.200| |-001.2| |-01.20|
    after    |-001.2| |-001.2| |-001.2| |-001.2|

…[macro_reexport]`)

and macros 2.0 exports (`pub use` macro re-exports and `pub macro` (once implemented)
at the crate root.

This seems to match other uses of "be accessed" in the document.

Fixes rust-lang#38723.

…rate::` path.

… to be more precise.

Fixes issue rust-lang#40408.

Change how the `0` flag works in format!

Now it always implies right-alignment, so that padding zeroes are placed after the sign (if any) and before the digits. In other words, it always takes precedence over explicitly specified `[[fill]align]`. This also affects the '#' flag: zeroes are placed after the prefix (0b, 0o, 0x) and before the digits.

Here's a short summary of how similar format strings work in Python and Rust:

```
              :05     :<05    :>05    :^05
Python 3.6  |-0001| |-1000| |000-1| |0-100|
Rust before |-0001| |-1000| |-0001| |-0100|
Rust after  |-0001| |-0001| |-0001| |-0001|

             :#05x   :<#05x  :>#05x  :^#05x
Python 3.6  |0x001| |0x100| |000x1| |00x10|
Rust before |0x001| |0x100| |000x1| |0x010|
Rust after  |0x001| |0x001| |0x001| |0x001|
```

Fixes rust-lang#39997 [breaking-change]

…, r=nrc

`TokenStream`-based attributes, paths in attribute and derive macro invocations

This PR
 - refactors `Attribute` to use  `Path` and `TokenStream` instead of `MetaItem`.
 - supports macro invocation paths for attribute procedural macros.
   - e.g. `#[::foo::attr_macro] struct S;`, `#[cfg_attr(all(), foo::attr_macro)] struct S;`
 - supports macro invocation paths for derive procedural macros.
   - e.g. `#[derive(foo::Bar, super::Baz)] struct S;`
 - supports arbitrary tokens as arguments to attribute procedural macros.
   - e.g. `#[foo::attr_macro arbitrary + tokens] struct S;`
 - supports using arbitrary tokens in "inert attributes" with derive procedural macros.
   - e.g. `#[derive(Foo)] struct S(#[inert arbitrary + tokens] i32);`
where `#[proc_macro_derive(Foo, attributes(inert))]`

r? @nrc

Handle extern functions and statics in save-analysis

r? @eddyb

Implement optimization fuel and re-enable struct field reordering

See [this discussion](https://internals.rust-lang.org/t/rolling-out-or-unrolling-struct-field-reorderings/4485) for background.

This pull request adds two new compilation options: `-Z print-fuel=crate` prints the optimization fuel used by a crate and `-Z fuel=crate=n` sets the optimization fuel for a crate.

It also turns field reordering back on.  There is no way to test this feature without something consuming fuel.  We can roll this back if we want, but then the optimization fuel bits will be dead code.

The one notable absence from this PR is a test case.  I'm not sure how to do one that's worth having.  The only thing I can think of to test is `-Z fuel=foo=0`.  The problem with other tests is that either (1) they're so big that future optimizations will apply, thus breaking them or (2) we don't know which order the optimizations will be applied in, so we can't guess the message that will be printed.  If someone has a useful proposal for a good test, I certainly want to add one.

Propagate expected type hints through struct literals.

Partial fix for rust-lang#31260 to maximize backwards-compatibility, i.e. the hint is provided but not coerced to.

The added test works because `{...; x}` with a hint of `T` coerces `x` to `T`, and the reasoning why that is slightly different has to do with DSTs: `&Struct { tail: [x] }: &Struct<[T]>` has a hint of `[T]` for `[x]`, but the inferred type should be `[T; 1]` to succeed later, so `[x]` shouldn't be *forced* to be `[T]`.

*However*, implementing that complete behavior in a backwards-compatible way may be non-trivial, and has not yet been fully investigated, while this PR fixes rust-lang#40355 and can be backported.

r? @nikomatsakis

Specialize Vec::from_elem to use calloc

Fixes rust-lang#38723.  This specializes the implementation for `u8` only, but it could be extended to other zeroable types if desired.

I haven't tested this extensively, but I did verify that it gives the expected performance boost for large `vec![0; n]` allocations with both alloc_system and jemalloc, on Linux.  (I have not tested or even built the Windows code.)

Add feature gate for rvalue-static-promotion

Probably needs more tests (which ones?) and there may be other things that need to be done. Also not sure whether the version that introduces the flag is really `1.15.1`.

See rust-lang/rfcs#1414.

Updates rust-lang#38865.

…rner

Point to let when modifying field of immutable variable

Point at the immutable local variable when trying to modify one of its
fields.

Given a file:

```rust
struct Foo {
    pub v: Vec<String>
}

fn main() {
    let f = Foo { v: Vec::new() };
    f.v.push("cat".to_string());
}
```

present the following output:

```
error: cannot borrow immutable field `f.v` as mutable
 --> file.rs:7:13
  |
6 |    let f = Foo { v: Vec::new() };
  |        - this should be `mut`
7 |    f.v.push("cat".to_string());
  |    ^^^

error: aborting due to previous error
```

Fix rust-lang#27593.

…orts, r=nrc

Forbid conflicts between macros 1.0 exports and macros 2.0 exports

This PR forbids for conflicts between `#[macro_export]`/`#[macro_reexport]` macro exports and `pub use` macro exports. For example,
```rust
// crate A:
pub use macros::foo;
//^ This is allowed today, will be forbidden by this PR.

// crate B:
extern crate A; // This triggers a confusing error today.
use A::foo; // This could refer to refer to either macro export in crate A.
```

r? @nrc

Implemente overflowing_sh* with new unchecked_sh* intrinsics

Also update some 128 bit builtins to not rely on the constant evaluator to avoid checked operations.

Fixes rust-lang#40508.

cc @nagisa, @alexcrichton

Note: I still have a build running to see if the 128 bit changes worked (unoptimized builds take *forever* to compile), however at least the overflowing builtins no longer reference `core::panicking::panic`.

add test for nested macro def (rust-lang#31946)

Adds a test for issue rust-lang#31946 which was fixed in 1.12.0.

Closes rust-lang#31946.

…r, r=nrc

macros: improve the `TokenStream` quoter

This PR
 - renames the `TokenStream` quoter from `qquote!` to `quote!`,
 - uses `$` instead of `unquote` (e.g. `let toks: TokenStream = ...; quote!([$toks])`),
 - allows unquoting `Token`s as well as `TokenTree`s and `TokenStream`s (fixes rust-lang#39746), and
 - to preserve syntactic space, requires that `$` be followed by
   - a single identifier to unquote, or
   - another `$` to produce a literal `$`.

r? @nrc

Library stabilizations for 1.17

Details of the stabilizations are available in the commits. Includes only library stabilizations; there are a couple of compiler stabilizations that should also be done for 1.17.

Will need a beta backport, which I will create after approval.

r? @alexcrichton

…wsxcv

Fix const not displayed in rustdoc

Fixes rust-lang#40331.

r? @rust-lang/docs

[LLVM 4.0] Add missing debuginfo metadata to globals

Fixes rust-lang#40580.

cc @rkruppe
cc rust-lang#40123

…ion, r=nrc

macros: fix regression with `include!()`

Fixes rust-lang#40469, a regression when `include!()`ing a `macro_rules!` containing `$crate`.
r? @nrc

…excrichton

Add a test for issue 34571

Closes rust-lang#34571.

… r=nagisa

Parse 0e+10 as a valid floating-point literal

Fixes issue rust-lang#40408.

documented order of conversion between u32 an ipv4addr

This fixes rust-lang#40118

…uillaumeGomez

minor wording tweak to slice::{as_ptr, as_mut_ptr}

Per rust-lang#37334, the slice-as-pointer methods mentioned that "modifying the slice may cause its buffer to be reallocated", when in fact modifying the *slice* itself would cause no such change. (It is a borrow, after all!) This is a tweak to the wording of that line to stress it's the *collection* that could cause the buffer to be reallocated.

r? @steveklabnik

Fix typo in mutex.rs docs

This seems to match other uses of "be accessed" in the document.

…sfackler

Fix a spelling error in HashMap documentation, and slightly reword surrounding text for precision

Noticed while reading docs just now.

It's possible that the prior wording *meant* to state that the seed's randomness depends on the exact instant that the system RNG was created, I guess.  But unless there's an API guarantee that this is the case, the wording seems over-precise.  Is there a formal API guarantee that would forbid, say, the system RNG from generating all output using the Intel RDRAND instruction?  I don't think the quality of output in that case would depend on when the RNG was created.  Yet it seems to me like it could well be a valid source of randomness when computing the initial seed.

For that reason, tying the randomness of the seed, to the quality of the RNG's output *at the precise instant the seed is computed*, seems less confining.  That instantaneous quality level could be determined by the quality at the instant the RNG was created -- but instantaneous quality need not be low for that precise reason.