Report const eval error inside the query
Functional changes: We no longer warn about bad constants embedded in unused types. This relied on being able to report just a warning, not a hard error on that case, which we cannot do any more now that error reporting is consistently centralized.
r? @RalfJung
fixes#53561
Miri engine cleanup
* Unify the two maps in memory to store the allocation and its kind together.
* Share the handling of statics between CTFE and miri: The miri engine always
uses "lazy" `AllocType::Static` when encountering a static. Acessing that
static invokes CTFE (no matter the machine). The machine only has any
influence when writing to a static, which CTFE outright rejects (but miri
makes a copy-on-write).
* Add an `AllocId` to by-ref consts so miri can use them as operands without
making copies.
* Move responsibilities around for the `eval_fn_call` machine hook: The hook
just has to find the MIR (or entirely take care of everything); pushing the
new stack frame is taken care of by the miri engine.
* Expose the intrinsics and lang items implemented by CTFE so miri does not
have to reimplement them.
* Allow Machine to hook into foreign statics (used by miri to get rid of some other hacks).
* Clean up function calling.
* Switch const sanity check to work on operands, not mplaces.
* Move const_eval out of rustc_mir::interpret, to make sure that it does not access private implementation details.
In particular, we can finally make `eval_operand` take `&self`. :-)
Should be merged after https://github.com/rust-lang/rust/pull/53609, across which I will rebase.
Use optimized SmallVec implementation
This PR replaces current SmallVec implementation with the one from the Servo project.
Closes https://github.com/rust-lang/rust/issues/51640
r? @Mark-Simulacrum
* Value gets renamed to Operand, so that now interpret::{Place, Operand} are the
"dynamic" versions of mir::{Place, Operand}.
* Operand and Place share the data for their "stuff is in memory"-base in a new
type, MemPlace. This also makes it possible to give some more precise types
in other areas. Both Operand and MemPlace have methods available to project
into fields (and other kinds of projections) without causing further
allocations.
* The type for "a Scalar or a ScalarPair" is called Value, and again used to
give some more precise types.
* All of these have versions with an attached layout, so that we can more often
drag the layout along instead of recomputing it. This lets us get rid of
`PlaceExtra::Downcast`. MPlaceTy and PlaceTy can only be constructed
in place.rs, making sure the layout is handled properly.
(The same should eventually be done for ValTy and OpTy.)
* All the high-level functions to write typed memory take a Place, and live in
place.rs. All the high-level typed functions to read typed memory take an
Operand, and live in operands.rs.
Exhaustive integer matching
This adds a new feature flag `exhaustive_integer_patterns` that enables exhaustive matching of integer types by their values. For example, the following is now accepted:
```rust
#![feature(exhaustive_integer_patterns)]
#![feature(exclusive_range_pattern)]
fn matcher(x: u8) {
match x { // ok
0 .. 32 => { /* foo */ }
32 => { /* bar */ }
33 ..= 255 => { /* baz */ }
}
}
```
This matching is permitted on all integer (signed/unsigned and char) types. Sensible error messages are also provided. For example:
```rust
fn matcher(x: u8) {
match x { //~ ERROR
0 .. 32 => { /* foo */ }
}
}
```
results in:
```
error[E0004]: non-exhaustive patterns: `32u8...255u8` not covered
--> matches.rs:3:9
|
6 | match x {
| ^ pattern `32u8...255u8` not covered
```
This implements https://github.com/rust-lang/rfcs/issues/1550 for https://github.com/rust-lang/rust/issues/50907. While there hasn't been a full RFC for this feature, it was suggested that this might be a feature that obviously complements the existing exhaustiveness checks (e.g. for `bool`) and so a feature gate would be sufficient for now.
Rollup of bare_trait_objects PRs
All deny attributes were moved into bootstrap so they can be disabled with a line of config.
Warnings for external tools are allowed and it's up to the tool's maintainer to keep it warnings free.
r? @Mark-Simulacrum
cc @ljedrz @kennytm
