Specify units for test timeout environment variables
I think it is not obvious (I got it from reading libtest sources), so it is worth mentioning in docs.
Prepare for LLVM 10 upgrade
Split off from #67759, this just adds the necessary compatibility bits and updates codegen tests, without performing the actual LLVM upgrade.
r? @alexcrichton
Split MIR building into its own crate
This moves `rustc_mir::{build, hair, lints}` to `rustc_mir_build`.
The new crate only has a `provide` function as it's public API.
Based on #67898
cc @Centril @rust-lang/compiler
r? @oli-obk
Add suggestions when encountering chained comparisons
Ideally, we'd also prevent the type error, which is just extra noise, but that will require moving the error from the parser, and I think the suggestion makes things clear enough for now.
Fixes https://github.com/rust-lang/rust/issues/65659.
Move more of `rustc::lint` into `rustc_lint`
Based on https://github.com/rust-lang/rust/pull/67806.
Here we try to consolidate more of the linting infra into `rustc::lint`. Some high-level notes:
- We now store an `Lrc<dyn Any + Send + Sync>` as opposed to `Lrc<LintStore>` in the `GlobalCtxt`. This enables us to avoid referring to the type, breaking a cyclic dependency, and so we can move things from `rustc::lint` to `rustc_lint`.
- `in_derive_expansion` is, and needs to, be moved as a method on `Span`.
- We reduce the number of ways on `tcx` to emit a lint so that the developer UX is more streamlined.
- `LintLevelsBuilder` is moved to `rustc_lint::levels`, leaving behind `LintLevelMap/Set` in a purified form due to current constraints (hopefully fixable in the future after https://github.com/rust-lang/rust/pull/68133).
- `struct_lint_level` is moved to `rustc::lint` due to current dependency constraints.
- `rustc::lint::context` is moved to `rustc_lint::context`.
- The visitors in `rustc::lint` are moved to `rustc_lint::passes`.
Galloping search for binary_search_util
This is unlikely to improve perf much unless for synthetic benchmarks, but I figure it likely won't hurt either.
Constify more of alloc::Layout
Making more methods of `alloc::Layout` const would allow us to compute alignment/size information for arbitrary (sized) types at compile-time, including placing the information in associated constants. While `mem::size_of` and `mem::align_of` are already const and `Layout` is solely based on those, there is no guarantee in the implementation that a const derived from these functions will be exactly the same as what `Layout` uses and is subsequently used in a call to `alloc::alloc`. Constifying `Layout` makes this possible.
First contribution to core, excuse my ignorance.
Don't require `allow_internal_unstable` unless `staged_api` is enabled.
#63770 changed `qualify_min_const_fn` to require `allow_internal_unstable` for *all* crates that used an unstable feature, regardless of whether `staged_api` was enabled or the `fn` that used that feature was stably const. In practice, this meant that every crate in the ecosystem that wanted to use nightly features added `#![feature(const_fn)]`, which skips `qualify_min_const_fn` entirely.
After this PR, crates that do not have `#![feature(staged_api)]` will only need to enable the feature they are interested in. For example, `#![feature(const_if_match)]` will be enough to enable `if` and `match` in constants. Crates with `staged_api` (e.g., `libstd`) require `#[allow_internal_unstable]` to be added to a function if it uses nightly features unless that function is also marked `#[rustc_const_unstable]`. This prevents proliferation of `#[allow_internal_unstable]` into functions that are not callable in a `const` context on stable.
r? @oli-obk (author of #63770)
cc @Centril
Compile some CGUs in parallel at the start of codegen
This brings the compilation time for `syntex_syntax` from 11.542s to 10.453s with 6 threads in non-incremental debug mode. Just compiling `n` CGUs in parallel at the beginning of codegen seems sufficient to get rid of the staircase effect, at least for `syntex_syntax`.
Based on https://github.com/rust-lang/rust/pull/67777.
r? @michaelwoerister
cc @alexcrichton @Mark-Simulacrum
