Extract `rustc_ast_passes`, move gating, & refactor linting
Based on https://github.com/rust-lang/rust/pull/67770.
This PR extracts a crate `rustc_ast_passes`:
- `ast_validation.rs`, which is contributed by `rustc_passes` (now only has HIR based passes) -- the goal here is to improve recompilation of the parser,
- `feature_gate.rs`, which is contributed by `syntax` and performs post-expansion-gating & final erroring for pre-expansion gating,
- `show_span`, which is contributed by `syntax`.
To facilitate this, we first have to also:
- Move `{leveled_}feature_err{_err}` from `syntax::feature_gate::check` into `rustc_session::parse`.
- Move `get_features` into `rustc_parse::config`, the only place it is used.
- Move some some lint datatypes and traits, e.g. `LintBuffer`, `BufferedEarlyLint`, `BuiltinLintDiagnostics`, `LintPass`, and `LintArray` into `rustc_session::lint`.
- Move all the hard-wired lint `static`s into `rustc_session::lint::builtin`.
build-std compatible sanitizer support
### Motivation
When using `-Z sanitizer=*` feature it is essential that both user code and
standard library is instrumented. Otherwise the utility of sanitizer will be
limited, or its use will be impractical like in the case of memory sanitizer.
The recently introduced cargo feature build-std makes it possible to rebuild
standard library with arbitrary rustc flags. Unfortunately, those changes alone
do not make it easy to rebuild standard library with sanitizers, since runtimes
are dependencies of std that have to be build in specific environment,
generally not available outside rustbuild process. Additionally rebuilding them
requires presence of llvm-config and compiler-rt sources.
The goal of changes proposed here is to make it possible to avoid rebuilding
sanitizer runtimes when rebuilding the std, thus making it possible to
instrument standard library for use with sanitizer with simple, although
verbose command:
```
env CARGO_TARGET_X86_64_UNKNOWN_LINUX_GNU_RUSTFLAGS=-Zsanitizer=thread cargo test -Zbuild-std --target x86_64-unknown-linux-gnu
```
### Implementation
* Sanitizer runtimes are no long packed into crates. Instead, libraries build
from compiler-rt are used as is, after renaming them into `librusc_rt.*`.
* rustc obtains runtimes from target libdir for default sysroot, so that
they are not required in custom build sysroots created with build-std.
* The runtimes are only linked-in into executables to address issue #64629.
(in previous design it was hard to avoid linking runtimes into static
libraries produced by rustc as demonstrated by sanitizer-staticlib-link
test, which still passes despite changes made in #64780).
cc @kennytm, @japaric, @firstyear, @choller
Standard library support for riscv64gc-unknown-linux-gnu
Add std support for RISC-V 64-bit GNU/Linux and update libc for RISC-V support.
r? @alexcrichton
This replaces cargo-fmt with rustfmt with --skip-children which should
allow us to format code without running into rust-lang/rustfmt#3930.
This also bumps up the version of rustfmt used to a more recent one.
Update cargo, books
Update nomicon, cargo, reference, book, rust-by-example, embedded-book
## nomicon
2 commits in 041c46e692a2592853aeca132c8dfe8eb5a79a9e..8be35b201f9cf0a4c3fcc96c83ac21671dcf3112
2019-11-20 16:46:45 +0100 to 2019-12-01 13:02:12 -0500
- Update unwinding.md
- ci: remove needless rust-docs component
## cargo
15 commits in 626f0f40efd32e6b3dbade50cd53fdfaa08446ba..5a139f7e6d67fd8a416a3f19d8e01581d24c0333
2019-12-03 16:53:04 +0000 to 2019-12-10 20:17:50 +0000
- Bump cargo-platform version. (rust-lang/cargo#7693)
- Add a test for `cargo locate-project` (rust-lang/cargo#7690)
- Emit error on [target.'cfg(debug_assertions)'.dependencies] and similar (rust-lang/cargo#7660)
- Update the layout of `Cargo Commands` in doc (rust-lang/cargo#7687)
- Features and dependencies can't have the same name (rust-lang/cargo#7682)
- Fix some typos in doc (rust-lang/cargo#7672)
- Add test for `NAME` environment variable when `cargo new` (rust-lang/cargo#7667)
- Add test for `GIT_COMMITTER_EMAIL` when `cargo new` (rust-lang/cargo#7666)
- document support for Bitbucket Pipelines badges (rust-lang/cargo#7663)
- Add cargo-vendor to the list of cargo commands in doc (rust-lang/cargo#7659)
- Fix typo in section 'Caching the Cargo home in CI' (rust-lang/cargo#7661)
- Docs: Add an appendix on git authentication. (rust-lang/cargo#7658)
- Remove --offline empty index error. (rust-lang/cargo#7655)
- Change the link destination of cargo book contribution (rust-lang/cargo#7657)
- Add a --offline hint. (rust-lang/cargo#7654)
## reference
2 commits in 9e843aeb4df083522c7277179bbaa25d0507731c..787e8d84034a4a0ae17084bbae25474152144b9a
2019-11-24 17:44:04 +0100 to 2019-12-10 10:01:29 -0800
- Update for visibility syntax changes. (rust-lang-nursery/reference#722)
- document `bind_by_move_pattern_guards` (rust-lang-nursery/reference#720)
## book
2 commits in 81ebaa2a3f88d4d106516c489682e64cacba4f60..ef8bb568035ded8ddfa30a9309026638cc3c8136
2019-11-15 08:30:04 -0800 to 2019-11-28 11:00:04 -0600
- Remove optional commas from match arms in ch18-03 (rust-lang/book#2176)
- Remove call_box() from ch20-03 (rust-lang/book#2177)
## rust-by-example
1 commits in 4835e025826729827a94fdeb7cb85fed288d08bb..b7ac1bc76b7d02a43c83b3a931d226f708aa1ff4
2019-11-14 09:20:43 -0300 to 2019-12-02 11:38:43 -0300
- Make TryFrom & TryInto example editable (rust-lang/rust-by-example#1297)
## embedded-book
1 commits in 5ca585c4a7552efb546e7681c3de0712f4ae4fdc..c26234930282210849256e4ecab925f0f2daf3be
2019-08-27 13:39:14 +0000 to 2019-12-07 17:25:11 +0000
- Fix `impl Gpio` -> `impl GpioConfig` (rust-embedded/book#216)
rustllvm relies on the `LLVMRustStringWriteImpl` symbol existing, but
this symbol was previously defined in a *downstream* crate
(rustc_codegen_llvm, which depends on rustc_llvm.
While this somehow worked under the old 'separate bootstrap step for
codegen' scheme, it meant that rustc_llvm could not actually be built by
itself, since it relied linking to the downstream rustc_codegen_llvm
crate.
Now that librustc_codegen_llvm is just a normal crate, we actually try
to build a standalone rustc_llvm when we run tests. This commit moves
`LLVMRustStringWriteImpl` into rustc_llvm (technically the rustllvm
directory, which has its contents built by rustc_llvm). This ensures
that we can build each crate in the graph by itself, without requiring
that any downstream crates be linked in as well.
This commit builds on #65501 continue to simplify the build system and
compiler now that we no longer have multiple LLVM backends to ship by
default. Here this switches the compiler back to what it once was long
long ago, which is linking LLVM directly to the compiler rather than
dynamically loading it at runtime. The `codegen-backends` directory of
the sysroot no longer exists and all relevant support in the build
system is removed. Note that `rustc` still supports a dynamically loaded
codegen backend as it did previously, it just no longer supports
dynamically loaded codegen backends in its own sysroot.
Additionally as part of this the `librustc_codegen_llvm` crate now once
again explicitly depends on all of its crates instead of implicitly
loading them through the sysroot. This involved filling out its
`Cargo.toml` and deleting all the now-unnecessary `extern crate`
annotations in the header of the crate. (this in turn required adding a
number of imports for names of macros too).
The end results of this change are:
* Rustbuild's build process for the compiler as all the "oh don't forget
the codegen backend" checks can be easily removed.
* Building `rustc_codegen_llvm` is much simpler since it's simply
another compiler crate.
* Managing the dependencies of `rustc_codegen_llvm` is much simpler since
it's "just another `Cargo.toml` to edit"
* The build process should be a smidge faster because there's more
parallelism in the main rustc build step rather than splitting
`librustc_codegen_llvm` out to its own step.
* The compiler is expected to be slightly faster by default because the
codegen backend does not need to be dynamically loaded.
* Disabling LLVM as part of rustbuild is still supported, supporting
multiple codegen backends is still supported, and dynamic loading of a
codegen backend is still supported.
