Right now the compiler's we're using actually default to armv7/thumb2 I believe,
so this should help push them back to what the arm-unknown-linux-* targets are
for. This at least matches that clang does for the `arm-unknown-linux-gnueabihf`
target which is to map it to an armv6 architecture.

Closes rust-lang#31787

The "A buffer that's too small" example was calling encode_utf8().

…ub extern crate

…code_utf16()`

`clean_srcpath` tries to make the source-path relative to `src_root`,
but this didn't work since `src_root` itself wasn't absolute.

This commit adds support for *truly* unstable options in the compiler, as well
as adding warnings for the start of the deprecation path of
unstable-but-not-really options. Specifically, the following behavior is now in
place for handling unstable options:

* As before, an unconditional error is emitted if an unstable option is passed
  and the `-Z unstable-options` flag is not present. Note that passing another
  `-Z` flag does not require passing `-Z unstable-options` as well.
* New flags added to the compiler will be in the `Unstable` category as opposed
  to the `UnstableButNotReally` category which means they will unconditionally
  emit an error when used on stable.
* All current flags are in a category where they will emit warnings when used
  that the option will soon be a hard error.

Also as before, it is intended that `-Z` is akin to `#![feature]` in a crate
where it is required to unlock unstable functionality. A nightly compiler which
is used without any `-Z` flags should only be exercising stable behavior.

…ty, r=nikomatsakis

This PR changes the visibility of extern crate declarations to match that of items (fixes rust-lang#26775).
To avoid breakage, the PR makes it a `public_in_private` lint to reexport a private extern crate, and it adds the lint `inaccessible_extern_crate` for uses of an inaccessible extern crate.

The lints can be avoided by making the appropriate `extern crate` declaration public.

…, r=nikomatsakis

This commit adds support for *truly* unstable options in the compiler, as well
as adding warnings for the start of the deprecation path of
unstable-but-not-really options. Specifically, the following behavior is now in
place for handling unstable options:

* As before, an unconditional error is emitted if an unstable option is passed
  and the `-Z unstable-options` flag is not present. Note that passing another
  `-Z` flag does not require passing `-Z unstable-options` as well.
* New flags added to the compiler will be in the `Unstable` category as opposed
  to the `UnstableButNotReally` category which means they will unconditionally
  emit an error when used on stable.
* All current flags are in a category where they will emit warnings when used
  that the option will soon be a hard error.

Also as before, it is intended that `-Z` is akin to `#![feature]` in a crate
where it is required to unlock unstable functionality. A nightly compiler which
is used without any `-Z` flags should only be exercising stable behavior.

Right now the compiler's we're using actually default to armv7/thumb2 I believe,
so this should help push them back to what the arm-unknown-linux-* targets are
for. This at least matches that clang does for the `arm-unknown-linux-gnueabihf`
target which is to map it to an armv6 architecture.

Closes rust-lang#31787

Fixes rust-lang#31788

The "A buffer that's too small" example was calling encode_utf**8**().

fixes rust-lang#26995

r? @alexcrichton

…ichton

This effectively only records associated items from either inherent impls or trait definitions in the search-index.

fixes rust-lang#31808

r? @alexcrichton