This allows you to distinguish between an option that defaulted, and an
option selected by the user

Optimization is now on by default. Closes #24405

r? @steveklabnik

Should land this, https://github.com/rust-lang/rust/pull/24270, and https://github.com/rust-lang/rust/pull/24245 before rolling another beta.

As pointed out in [RFC issue 1043][rfc] it is quite useful to have the standard
I/O types to provide the contract that they are the sole owner of the underlying
object they represent. This guarantee enables writing safe interfaces like the
`MemoryMap` API sketched out in that issue.

[rfc]: https://github.com/rust-lang/rfcs/issues/1043

As constructing objects from these raw handles may end up violating these
ownership gurantees, the functions for construction are now marked unsafe.

[breaking-change]
Closes rust-lang/rfcs#1043

The current implementation of using GetFinalPathNameByHandle actually reads all
intermediate links instead of just looking at the current link. This commit
alters the behavior of the function to use a different API which correctly reads
only one level of the soft link.

[breaking-change]

Make sure the unstable `scoped` modules isn't named the same as the `scoped`
function.

cc #24334

This PR makes `rustc` emit field names for tuple fields in DWARF. Formerly there was no way of directly accessing the fields of a tuple in GDB and LLDB since there is no C/C++ equivalent to this. Now, the debugger sees the name `__{field-index}` for tuple fields. So you can type for example `some_tuple_val.__2` to get the third tuple component.
When pretty printers are used (e.g. via `rust-gdb` or `rust-lldb`) these artificial field names will not clutter tuple rendering (which was the main motivation for not doing this in the past).

Solves #21948.

On linux, certain crashes can cause rust's backtrace generation code to consume huge amounts of memory (multiple gigabytes) when trying to generate a backtrace (e.g. servo/servo#5340).

I tracked this down to a bug in libbacktrace's allocation strategy when processing large binaries, and thankfully it's already been fixed upstream.

The change which fixes this specific issue is r210256, and is discussed here:
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00547.html

I assume we'd prefer to update libbacktrace wholesale, rather than cherry-picking individual patches, so this PR updates libbacktrace to the latest code from svn://gcc.gnu.org/svn/gcc/trunk/libbacktrace (r220112).

I've copied the upstream code and reapplied the parts of the following commits which touch src/libbacktrace:

 - cd8f3175
 - fcb30a0b

I have not reapplied f5765793 or d51047de, as those are both cosmetic cleanups applied to the entire codebase. For this directory, it seems worthwhile diverging as little as possible from upstream, to reduce the effort of future updates. But I can add them as well if preferred.

The regex crate keeps its own tables now (rust-lang/regex#41) so we
don't need them here.

[breaking-change]

There are syntax extensions that call `std::rt::begin_unwind` passing it a `usize`.  I updated the syntax extension to instead pass `u32`, but for bootstrapping reasons, I needed to create a `#[cfg(stage0)]` version of `std::rt::begin_unwind` and therefore also `panic!`.

Make sure the unstable `scoped` modules isn't named the same as the `scoped`
function.

cc #24334

Also add docs because not being able to discover these things is the pits.

This was lifted from http://blog.jgc.org/2015/04/the-one-line-you-should-add-to-every.html , and solves a problem I've solved myself a *lot* of times, often in massively inferior ways.

Super open to documenting it somewhere other than nitty-gritty, which isn't immediately obvious.

Right now, if the user requests to increase the vector size via reserve() or push_back() and the request brings the attempted memory above usize::MAX, we panic.

With this change there is only a panic if the minimum requested memory that could meet the requirement is above usize::MAX- otherwise it simply requests its largest capacity possible, usize::MAX.

The regex crate keeps its own tables now (rust-lang/regex#41) so we
don't need them here.

[breaking-change]

- Successful merges: #24072, #24233, #24321, #24339, #24341, #24342, #24347
- Failed merges: 

Docs meant that ParseIntError is returned though the function returns ParseFloatError.

with "let" when building on stage0. So change the error
message to a static const.

Also fixed bug calling .note() instead of .help()

See #24036

The "static and dynamic dispatch" chapter seems to no longer exist but there is a dead link from the Traits chapter pointing to it.

Have changed the link to point to "Trait Objects" which covers static and dynamic dispatch.

Closes #16602

Also fixed bug calling .note() instead of .help()

See #24036

Docs meant that Option is returned though the function returns Result.

 * In `noop_fold_expr`, call `new_span` in these cases:
    - `ExprMethodCall`'s identifier
    - `ExprField`'s identifier
    - `ExprTupField`'s integer

   Calling `new_span` for `ExprMethodCall`'s identifier is necessary to print
   an acceptable diagnostic for `write!(&2, "")`. We see this error:
   ```
   <std macros>:2:20: 2:66 error: type `&mut _` does not implement any method in scope named `write_fmt`
   <std macros>:2 ( & mut * $ dst ) . write_fmt ( format_args ! ( $ ( $ arg ) * ) ) )
                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   ```
   With this change, we also see a macro expansion backtrace leading to
   the `write!(&2, "")` call site.

 * After fully expanding a macro, we replace the expansion expression's
   span with the original span. Call `fld.new_span` to add a backtrace to
   this span. (Note that I'm call `new_span` after `bt.pop()`, so the macro
   just expanded isn't on the backtrace.)

   The motivating example for this change is `println!("{}")`. The format
   string literal is `concat!($fmt, "arg")` and is inside the libstd macro.
   We need to see the backtrace to find the `println!` call site.

 * Add a backtrace to the `format_args!` format expression span.

r?  alexcrichton

Addresses #23459

Fix #23896.

We provide tools to tell what exact symbols to emit for any fn or static, but
don’t quite check if that won’t cause any issues later on. Some of the issues
include LLVM mangling our names again and our names pointing to wrong locations,
us generating dumb foreign call wrappers, linker errors, extern functions
resolving to different symbols altogether (`extern {fn fail();} fail();` in some
cases calling `fail1()`), etc.

Before the commit we had a function called `note_unique_llvm_symbol`, so it is
clear somebody was aware of the issue at some point, but the function was barely
used, mostly in irrelevant locations.

Along with working on it I took liberty to start refactoring trans/base into
a few smaller modules. The refactoring is incomplete and I hope I will find some
motivation to carry on with it.

This is possibly a [breaking-change] because it makes dumbly written code
properly invalid.

This fixes all those issues about incorrect use of #[no_mangle] being not reported/misreported/ICEd by the compiler.

NB. This PR does not attempt to tackle the parallel codegen issue that was mentioned in https://github.com/rust-lang/rust/pull/22811, but I believe it should be very straightforward in a follow up PR by modifying `trans::declare::get_defined_value` to look at all the contexts.

cc @alexcrichton @huonw @nrc because you commented on the original RFC issue.

EDIT: wow, this became much bigger than I initially intended.

It was added in 2011-08-05 and reduced to a no-op ten days later.

 * In noop_fold_expr, call new_span in these cases:
    - ExprMethodCall's identifier
    - ExprField's identifier
    - ExprTupField's integer

   Calling new_span for ExprMethodCall's identifier is necessary to print
   an acceptable diagnostic for write!(&2, ""). We see this error:

       <std macros>:2:20: 2:66 error: type `&mut _` does not implement any method in scope named `write_fmt`
       <std macros>:2 ( & mut * $ dst ) . write_fmt ( format_args ! ( $ ( $ arg ) * ) ) )
                                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

   With this change, we also see a macro expansion backtrace leading to
   the write!(&2, "") call site.

 * After fully expanding a macro, we replace the expansion expression's
   span with the original span. Call fld.new_span to add a backtrace to
   this span. (Note that I'm call new_span after bt.pop(), so the macro
   just expanded isn't on the backtrace.)

   The motivating example for this change is println!("{}"). The format
   string literal is concat!($fmt, "arg") and is inside the libstd macro.
   We need to see the backtrace to find the println! call site.

 * Add a backtrace to the format_args! format expression span.

Addresses #23459

This fixes the bug described in issue #23150.  This affected formatting any floating point number into a string in a formatting pattern that: a) required rounding up, and b) required an extra digit on the front.

So `format!("{:.0}", 9.9)` would fail, but `format!("{:.0}", 8.9)` would succeed.  This was due to a negative integer being cast to a `usize` resulting in an 'arithmetic operation overflowed' panic.

The fix was to change the order of operations so that the number is zero before casting.