`check_match` creates a new `TypedArena` for every call to
`create_and_enter`. DHAT tells me that each `TypedArena` typically is
barely used, with typically a single allocation per arena.

This commit moves the `TypedArena` creation outwards a bit, into
`check_match`, and then passes it into `create_and_enter`. This reduces
the number of arenas created by about 4-5x, for a very small perf win.
(Moving the arena creation further outwards is hard because
`check_match` is a query.)

At this time Apple recommends Bitcode be included for iOS apps, and
requires it for tvOS. It is unlikely that a developer would want to
disable bitcode when building for these targets, yet by default it will
not be generated. This presents a papercut for developers on those
platforms.

Introduces a new TargetOption boolean key for specific triples to
indicate that bitcode should be generated, even if cargo attempts to
optimise with -Cembed-bitcode=no.

The App Store performs certain sanity checks on bitcode, including that
an acceptable set of command line arguments was used when compiling a
given module. For Rust code to be distributed on the app store with
bitcode rustc must pretend to have the same command line arguments.

It has a single call site.

The closure isn't necessary.

…, r=kinnison

Unify lints handling in rustdoc

This is a small cleanup. The goal is to unify a bit things to make the reading simpler.

r? @kinnison

cc @rust-lang/rustdoc

…r=nikomatsakis

Test for zero-sized function items not ICEing

Closes rust-lang#30276.
Again.
Please give rustcake with no icing!

…r=alexcrichton

Improve bitcode generation for Apple platforms

Some improvements for iOS bitcode support suggested by Alex over at getditto/rust-bitcode#9. r? @alexcrichton

This improves Rust's bitcode generation so that provided you have a compatible LLVM version, Rust targeting iOS should work out of the box when compiled into bitcode-enabled apps, and when submitted to the App Store. I've tested these changes using Xcode 11.4.1 and Apple's vendored LLVM, [tag `swift-5.2.3-RELEASE`](https://github.com/apple/llvm-project/releases/tag/swift-5.2.3-RELEASE).

1. Force `aarch64-apple-ios` and `aarch64-apple-tvos` targets to always emit full bitcode sections, even when cargo is trying to optimise by invoking `rustc` with `-Cembed-bitcode=no`. Since Apple recommends bitcode on iOS and requires it on tvOS it is likely that this is what developers intend. Currently you need to override the codegen options with `RUSTFLAGS`, which is far from obvious.
2. Provide an LLVM cmdline in the target spec. Apple's bitcode verification process looks for some arguments. For Rust modules to be accepted we must pretend they were produced similarly. A suitable default is provided in `TargetOptions` for iOS, copied directly from the a clang equivalent section.

In the context of Apple platforms, the predominant purpose of bitcode is App Store submissions, so simulator and 32-bit targets are not relevant. I'm hoping that the cmdline strings will not be a maintenance burden to keep up-to-date. If the event of any future incompatibilities, hopefully a custom target config would offer enough flexibility to work around it. It's impossible to say for sure.

Due to unrelated build errors I haven't been able to build and test a full tvOS toolchain. I've stopped short of providing a similar `bitcode_llvm_cmdline` until I can actually test it.

…ions-in-check_match, r=oli-obk

Reduce `TypedArena` creations in `check_match`.

`check_match` creates a new `TypedArena` for every call to
`create_and_enter`. DHAT tells me that each `TypedArena` typically is
barely used, with typically a single allocation per arena.

This commit moves the `TypedArena` creation outwards a bit, into
`check_match`, and then passes it into `create_and_enter`. This reduces
the number of arenas created by about 4-5x, for a very small perf win.
(Moving the arena creation further outwards is hard because
`check_match` is a query.)

r? @oli-obk

allow wasm target for rustc-ap-rustc_span

This fixes rust-lang#71998 by applying the work-a-round. The root cause is probably rust-lang#56935, as @petrochenkov pointed out.

I reproduced the bug by:
```
cd ~/.cargo/registry/src/github.com-1ecc6299db9ec823/rustc-ap-rustc_span-657.0.0/
cargo build --target wasm32-unknown-unknown
```

Adding this line fixes it.

Work around ICEs during cross-compilation for target, ast, & attr

This applies the fix for rust-lang#72003 to work around rust-lang#56935 to three more libraries. With these additional fixes, I'm able to use rustfmt_lib from wasm (rust-lang/rustfmt#4132 (comment)), which was my goal.

To get it working locally and to test, I copied the `.cargo/registry/src` and applied the fix and replaced the reference in my project:
``` toml
[replace]
"rustc-ap-rustc_span:656.0.0" = { path = "../rustc-ap-rustc_span" }
"rustc-ap-rustc_target:656.0.0" = { path = "../rustc-ap-rustc_target" }
"rustc-ap-rustc_ast:656.0.0" = { path = "../rustc-ap-rustc_ast" }
"rustc-ap-rustc_attr:656.0.0" = { path = "../rustc-ap-rustc_attr" }
```