Add a HIR pass to check consts for `if`, `loop`, etc.
Resolves#66125.
This PR adds a HIR pass to check for high-level control flow constructs that are forbidden in a const-context. The MIR const-checker is unable to provide good spans for these since they are lowered to control flow primitives (e.g., `Goto` and `SwitchInt`), and these often don't map back to the underlying statement as a whole. This PR is intended only to improve diagnostics once `if` and `match` become commonplace in constants (behind a feature flag). The MIR const-checker will continue to operate unchanged, and will catch anything this check might miss.
In this implementation, the HIR const-checking pass is run much earlier than the MIR one, so it will supersede any errors from the latter. I will need some mentoring if we wish to change this, since I'm not familiar with the diagnostics system. Moving this pass into the same phase as the MIR const-checker could also help keep backwards compatibility for items like `const _: () = loop { break; };`, which are currently (erroneously?) accepted by the MIR const-checker (see #62272).
r? @Centril
cc @eddyb (since they filed #62272)
This PR BREAKS CODE THAT WAS ACCEPTED ON STABLE. It's arguably a bug
that this was accepted in the first place, but here we are. See #62272
for more info.
These errors will be triggered before the MIR const-checker runs,
causing all other errors to be silenced. They are now checked in the
`const-{if,loop}` tests.
These high-level constructs get mapped to control-flow primitives by the
time the MIR const-checker runs, making it hard to get the span for the
erroneous expression.
Rollup of 14 pull requests
Successful merges:
- #65932 (download .tar.xz if python3 is used)
- #66094 (Fix documentation for `Iterator::count()`.)
- #66166 (rename cfg(rustdoc) into cfg(doc))
- #66186 (Add long error explanation for E0623)
- #66227 (docs: Fix link to BufWriter::flush)
- #66248 (add raw ptr variant of UnsafeCell::get)
- #66292 (add Result::map_or)
- #66297 (Add a callback that allows compiler consumers to override queries.)
- #66317 (Use a relative bindir for rustdoc to find rustc)
- #66330 (Improve non-exhaustiveness handling in usefulness checking)
- #66331 (Add some tests for fixed ICEs)
- #66334 (Move Session fields to CrateStore)
- #66335 (Move self-profile infrastructure to data structures)
- #66337 (Remove dead code for encoding/decoding lint IDs)
Failed merges:
r? @ghost
Move self-profile infrastructure to data structures
The single dependency on queries (QueryName) can be fairly easily
abstracted via a trait and this further decouples Session from librustc
(the primary goal).
This is intended as a precursor to moving Session out of librustc, but since that involves lots of smaller steps that move around code I'm splitting it up into separate PRs.
Move Session fields to CrateStore
`allocator_kind` and `injected_panic_runtime` are both query-like, this moves them out of Session and into CrateStore, avoiding the `Once` they previously had by clearing separating initialization and de-initialization.
Add some tests for fixed ICEs
Closes#30904 (fixed between nightly-2019-07-14 and nightly-2019-07-31)
Closes#40231 (example 1 is fixed in 1.32.0, example 2 is fixed in 1.38.0)
Closes#52432 (fixed in rustc 1.40.0-beta.1 (76b40532a 2019-11-05))
Closes#63279 (fixed in rustc 1.40.0-nightly (246be7e1a 2019-10-25))
r? @Centril
Improve non-exhaustiveness handling in usefulness checking
The comments around code paths for the `non_exhaustive` feature mention stuff like "we act as if the type had an extra unmatcheable constructor". So I thought I'd make this explicit by defining a special constructor that does exactly this.
This makes those code paths a bit more legible and less prone to error.
Use a relative bindir for rustdoc to find rustc
In bootstrap, we set `RUSTC_INSTALL_BINDIR` to `config.bindir`, so
rustdoc can find rustc relative to the toolchain sysroot. However, if a
distro script like Fedora's `%configure` sets an absolute path, then
rustdoc's `sysroot.join(bin_path)` ignores that sysroot altogether.
That would be OK once the toolchain is actually installed, but it breaks
the in-tree doc tests during the build, since `/usr/bin/rustc` is still
the old version. So now we try to make `RUSTC_INSTALL_BINDIR` relative
to the sysroot prefix in the first place.
r? @Mark-Simulacrum
Add a callback that allows compiler consumers to override queries.
This pull request adds an additional callback that allows compiler consumers such as Prusti and MIRAI to override queries. My hope is that in this way it will be possible to get access to the internal compiler information (e.g. borrow checker) without major changes to the compiler.
This pull request is work in progress because I am still testing if I can get the information which I need.
cc @nikomatsakis
r? @oli-obk
add Result::map_or
This PR adds this API to make it consistent with `Option::map_or`.
```rust
impl<T, E> Result<T, E> {
pub fn map_or<U, F: FnOnce(T) -> U>(self, default: U, f: F) -> U {
match self {
Ok(t) => f(t),
Err(_) => default,
}
}
}
```
This API is very small. We already has a similar API for `Option::map_or`.
add raw ptr variant of UnsafeCell::get
This has come up recently in https://github.com/rust-lang/rust/pull/66051 (Cc @Centril @pitdicker) as well as in discussion with @nikomatsakis and in unrelated discussion with @withoutboats.
docs: Fix link to BufWriter::flush
One of the links in the docs was being rendered as a literal
open-bracket followed by a single quote, instead of being transformed
into a link. Fix it to match the link earlier in the same paragraph.
Fix documentation for `Iterator::count()`.
The documentation of std::core::Iterator::count() stated that the number returned is the number of times `next` is called on the iterator. However this is not true as the number of times `next` is called is exactly one plus the number returned by `count()`.
proposal for BTreeMap/Set min/max, #62924
- Which pair of names: #62924 lists the existing possibilities min/max, first/last, (EDIT) front/back, peek(/peek_back?). Iterators have next/next_back or next/last. I'm slightly in favour of first/last because min/max might suggest they search over the entire map, and front/back pretends they are only about position.
- Return key only instead of pair like iterator does?
- If not, then keep the _key_value suffix? ~~Also provide variant with mutable value? But there is no such variant for get_key_value.~~
- Look for and upgrade more usages of `.iter().next()` and such in the libraries? I only upgraded the ones I contributed myself, all very recently.
Add hooks for Miri panic unwinding
This commits adds in some additional hooks to allow Miri to properly
handle panic unwinding. None of this should have any impact on CTFE mode
This supports https://github.com/rust-lang/miri/pull/693
Fix MIR lowering evaluation order and soundness bug
* Fixes a soundness issue with built-in index operations
* Ensures correct evaluation order of assignment expressions where the RHS is a FRU or is a use of a local of reference type.
* Removes an unnecessary symbol to string conversion
closes#65909closes#65910
The single dependency on queries (QueryName) can be fairly easily
abstracted via a trait and this further decouples Session from librustc
(the primary goal).
