Don't try to force_ptr pointers to zsts
r? @RalfJung
cc @wesleywiser
This is required to fix miri after https://github.com/rust-lang/rust/pull/67501 broke it. The reason only miri sees this is that it uses validation on values during interpretation and not just on the final value of constants, which never contain such values.
Error codes checkup and rustdoc test fix
This PR does a few things:
* fix how rustdoc checks that an error code has been thrown (it only checked for "E0XXX" so if it appeared in the output because the file has it in its name or wherever, it passed the test, which was incorrect)
* fix the failing code examples that weren't throwing the expected error code
Rollup of 8 pull requests
Successful merges:
- #67313 (Document more use cases of dataflow)
- #67959 (rustdoc: improve stability mark arrows)
- #68097 (Specify units for test timeout environment variables)
- #68135 (restore some rustc_parse visibilities for rustfmt)
- #68145 (Expose `context::CheckLintNameResult`)
- #68156 (Fix crate paths in comments)
- #68157 (Clean up E0186 explanation)
- #68161 (Fix system call docs for time::Instant)
Failed merges:
r? @ghost
Fix system call docs for time::Instant
The link for UNIX was pointing to the Cloud ABI docs. It should have been pointing to the `clock_gettime` docs instead. A similar table is repeated in the docs for `SystemTime`, but there the UNIX entry was already correct.
`clock_gettime(CLOCK_MONOTONIC)` is the current implementation: 3ebcfa1451/src/libstd/sys/unix/time.rs (L274)3ebcfa1451/src/libstd/sys/unix/time.rs (L348-L352)
r? @steveklabnik
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
The link for UNIX was pointing to the Cloud ABI docs. It should have
been pointing to the clock_gettime docs instead. The table is repeated
in the docs for SystemTime, but there the UNIX entry was already correct.
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
