Fixes #20467

When trying to build against a newer, local LLVM version it might be
preferable to have a flag to disable the LLVM version check instead of
having to modify the configure script.

Fixes #21998

the sed option `--in-place` (or `-i`) is a GNU extension, and it is not
portable to BSD system (openbsd and freebsd checked).

use an alternate construction in order to keep the semantic.

None of the others work, so let's remove them.

Fixes #17220.

Fixes #13179

Fixes #13082

This pulls all of our long-form documentation into a single document,
nicknamed "the book" and formally titled "The Rust Programming
Language."

A few things motivated this change:

* People knew of The Guide, but not the individual Guides. This merges
  them together, helping discoverability.
* You can get all of Rust's longform documentation in one place, which
  is nice.
* We now have rustbook in-tree, which can generate this kind of
  documentation. While its style is basic, the general idea is much
  better: a table of contents on the left-hand side.
* Rather than a almost 10,000-line guide.md, there are now smaller files
  per section.

This partially implements the feature staging described in the
[release channel RFC][rc]. It does not yet fully conform to the RFC as
written, but does accomplish its goals sufficiently for the 1.0 alpha
release.

It has three primary user-visible effects:

* On the nightly channel, use of unstable APIs generates a warning.
* On the beta channel, use of unstable APIs generates a warning.
* On the beta channel, use of feature gates generates a warning.

Code that does not trigger these warnings is considered 'stable',
modulo pre-1.0 bugs.

Disabling the warnings for unstable APIs continues to be done in the
existing (i.e. old) style, via `#[allow(...)]`, not that specified in
the RFC. I deem this marginally acceptable since any code that must do
this is not using the stable dialect of Rust.

Use of feature gates is itself gated with the new 'unstable_features'
lint, on nightly set to 'allow', and on beta 'warn'.

The attribute scheme used here corresponds to an older version of the
RFC, with the `#[staged_api]` crate attribute toggling the staging
behavior of the stability attributes, but the user impact is only
in-tree so I'm not concerned about having to make design changes later
(and I may ultimately prefer the scheme here after all, with the
`#[staged_api]` crate attribute).

Since the Rust codebase itself makes use of unstable features the
compiler and build system to a midly elaborate dance to allow it to
bootstrap while disobeying these lints (which would otherwise be
errors because Rust builds with `-D warnings`).

This patch includes one significant hack that causes a
regression. Because the `format_args!` macro emits calls to unstable
APIs it would trigger the lint.  I added a hack to the lint to make it
not trigger, but this in turn causes arguments to `println!` not to be
checked for feature gates. I don't presently understand macro
expansion well enough to fix. This is bug #20661.

Closes #16678

[rc]: https://github.com/rust-lang/rfcs/blob/master/text/0507-release-channels.md

Adds AArch64 knowledge to:
* configure,
* make files,
* sources,
* tests, and
* documentation.

We have a default value for this ('/usr/local'), so this warning is
printed ALL the time unless one does --enable-local-rust. As a result,
it doesn't really help at all.

not in hardcoded libdir path. If there was no LIBDIR provided
during configuration fallback to hardcoded paths.

Thanks to Jan Niklas Hasse for solution and to Alex Crichton for improvements.

Closes #11671

Removes all target-specific knowledge from rustc. Some targets have changed
during this, but none of these should be very visible outside of
cross-compilation. The changes make our targets more consistent.

iX86-unknown-linux-gnu is now only available as i686-unknown-linux-gnu. We
used to accept any value of X greater than 1. i686 was released in 1995, and
should encompass the bare minimum of what Rust supports on x86 CPUs.

The only two windows targets are now i686-pc-windows-gnu and
x86_64-pc-windows-gnu.

The iOS target has been renamed from arm-apple-ios to arm-apple-darwin.

A complete list of the targets we accept now:

arm-apple-darwin
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf

i686-apple-darwin
i686-pc-windows-gnu
i686-unknown-freebsd
i686-unknown-linux-gnu

mips-unknown-linux-gnu
mipsel-unknown-linux-gnu

x86_64-apple-darwin
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu
x86_64-pc-windows-gnu

Closes #16093

[breaking-change]

Used aforementioned variants to extract options that have explicit
`putvar` calls associated with them in the subsequent code.  When the
explicit `putvar` call was conditional on some potentially complex
condition, moved the `putvar` call out to the main control flow of the
script so that it always runs if necessary.

----

As a driveby fix, captured the error exit when doing the test run of
`rustc --version` from `CFG_LOCAL_RUST_ROOT`, and signal explicit
configure failure when it did not run successfully.  (If we cannot run
`rustc`, we really shouldn't try to keep going.)

----

Finally, in response to review feedback, went through and identified
cases where we had been calling `putvar` manually (and thus my naive
translation used `opt_nosave`/`valopt_nosave`), and then verified
whether a manual `putvar` was necessary (i.e., was each variable in
question manually computed somewhere in the `configure` script).
In cases that did not meet this criteria, I revised the code to use
the `opt`/`valopt` directly and removed the corresponding `putvar`,
cleaning things up a teeny bit.

----

Fix #17887.

The goal here is to make it easier to add new platform definitions,
especially when the additions are programmatic (ie: in build scripts).

Closes #16914

Fixes #16983.

This commit removes the libuv and gyp submodules, as well as all build
infrastructure related to them.

For more context, see the [runtime removal
RFC](https://github.com/rust-lang/rfcs/pull/230)

[breaking-change]