| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
issue #53643
|
|
Fix issue #52475: Make loop detector only consider reachable memory
As [suggested](https://github.com/rust-lang/rust/pull/51702#discussion_r197585664) by @oli-obk `alloc_id`s should be ignored by traversing all `Allocation`s in interpreter memory at a given moment in time, beginning by `ByRef` locals in the stack.
- [x] Generalize the implementation of `Hash` for `EvalSnapshot` to traverse `Allocation`s
- [x] Generalize the implementation of `PartialEq` for `EvalSnapshot` to traverse `Allocation`s
- [x] Commit regression tests
Fixes #52626
Fixes https://github.com/rust-lang/rust/issues/52849
|
|
|
|
|
|
|
|
Implement the `min_const_fn` feature gate
cc @RalfJung @eddyb
r? @Centril
implements the feature gate for #53555
I added a hack so the `const_fn` feature gate also enables the `min_const_fn` feature gate. This ensures that nightly users of `const_fn` don't have to touch their code at all.
The `min_const_fn` checks are run first, and if they succeeded, the `const_fn` checks are run additionally to ensure we didn't miss anything.
|
|
Do not used Move data flow analysis, make it lazy instead
Close #53394
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
* 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.
|
|
Tidy CFTE/MIRI
Fixes #53596
|
|
MIR: support user-given type annotations on fns, structs, and enums
This branch adds tooling to track user-given type annotations on functions, structs, and enum variant expressions. The user-given types are passed onto NLL which then enforces them.
cc #47184 — not a complete fix, as there are more cases to cover
r? @eddyb
cc @rust-lang/wg-compiler-nll
|
|
|
|
|
|
use String::new() instead of String::from(""), "".to_string(), "".to_owned() or "".into()
|
|
|
|
|
|
|
|
|
|
or "".into()
|
|
|
|
oli-obk:dont_you_hate_it_too_when_everything_panics_constantly, r=eddyb
Allow panicking with string literal messages inside constants
r? @eddyb
cc https://github.com/rust-lang/rust/issues/51999
we can't implement things like `panic!("foo: {}", x)` right now because we can't call trait methods (most notably `Display::fmt`) inside constants. Also most of these impls probably have loops and conditions, so it's messy anyway.
But hey `panic!("foo")` works at least.
cc @japaric got any test ideas for `#![no_std]`?
|
|
|
|
|
|
Ty{Adt|Array|Slice|RawPtr|Ref|FnDef|FnPtr|Dynamic|Closure|Generator|GeneratorWitness|Never|Tuple|Projection|Anon|Infer|Error}
|
|
|
|
|
|
|
|
|
|
* 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.
|
|
|
|
Preliminary work for incremental ThinLTO (CGU name edition)
Bring back the first half of #52266 but hopefully without the performance regression.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
