| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
Don't format!() string literals
Prefer `to_string()` to `format!()` take 2, this time targetting string literals. In some cases (`&format!("...")` -> `"..."`) also removes allocations. Occurences of `format!("")` are changed to `String::new()`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This removes the `usize` argument to `inc_step_counter`. Now, the step
counter increments by exactly one for every terminator evaluated. After
`STEPS_UNTIL_DETECTOR_ENABLED` steps elapse, the detector is run every
`DETECTOR_SNAPSHOT_PERIOD` steps. The step counter is only kept modulo
this period.
|
|
|
|
The detector runs every `DETECTOR_SNAPSHOT_PERIOD` steps. Since the
number of steps can increase by more than 1 (I'd like to remove this),
the detector may fail if the step counter is incremented past the
scheduled detection point during the loop.
|
|
|
|
Incorporate a subset of the suggestions from @oli-obk. More to come.
|
|
This reverts commit 59d21c526c036d7097d05edd6dffdad9c5b1cb62, and uses
tuple to store the mutable parts of an EvalContext (which now includes
`Machine`). This requires that `Machine` be `Clone`.
|
|
Use the approach suggested by @oli-obk, a table holding `EvalState`
hashes and a table holding full `EvalState` objects. When a hash
collision is observed, the state is cloned and put into the full
table. If the collision was not spurious, it will be detected during the
next iteration of the infinite loop.
|
|
I use a pattern binding in each custom impl, so that adding fields to
`Memory` or `Frame` will cause a compiler error instead of causing e.g.
`PartialEq` to become invalid. This may be too cute.
This adds several requirements to `Machine::MemoryData`. These can be
removed if we don't want this associated type to be part of the equality
of `Memory`.
|
|
Change surrounding code to use accessor methods to refer to these fields.
Similar changes have not yet been made in tools/miri
|
|
Refactored code accordingly.
|
|
Loosened rules involving statics mentioning other statics
Before this PR, trying to mention a static in any way other than taking a reference to it caused a compile-time error. So, while
```rust
static A: u32 = 42;
static B: &u32 = &A;
```
compiles successfully,
```rust
static A: u32 = 42;
static B: u32 = A; // error
```
and
```rust
static A: u32 = 42;
static B: u32 = *&A; // error
```
are not possible to express in Rust. On the other hand, introducing an intermediate `const fn` can presently allow one to do just that:
```rust
static A: u32 = 42;
static B: u32 = foo(&A); // success!
const fn foo(a: &u32) -> u32 {
*a
}
```
Preventing `const fn` from allowing to work around the ban on reading from statics would cripple `const fn` almost into uselessness.
Additionally, the limitation for reading from statics comes from the old const evaluator(s) and is not shared by `miri`.
This PR loosens the rules around use of statics to allow statics to evaluate other statics by value, allowing all of the above examples to compile and run successfully.
Reads from extern (foreign) statics are however still disallowed by miri, because there is no compile-time value to be read.
```rust
extern static A: u32;
static B: u32 = A; // error
```
This opens up a new avenue of potential issues, as a static can now not just refer to other statics or read from other statics, but even contain references that point into itself.
While it might seem like this could cause subtle bugs like allowing a static to be initialized by its own value, this is inherently impossible in miri.
Reading from a static causes the `const_eval` query for that static to be invoked. Calling the `const_eval` query for a static while already inside the `const_eval` query of said static will cause cycle errors.
It is not possible to accidentally create a bug in miri that would enable initializing a static with itself, because the memory of the static *does not exist* while being initialized.
The memory is not uninitialized, it is not there. Thus any change that would accidentally allow reading from a not yet initialized static would cause ICEs.
Tests have been modified according to the new rules, and new tests have been added for writing to `static mut`s within definitions of statics (which needs to fail), and incremental compilation with complex/interlinking static definitions.
Note that incremental compilation did not need to be adjusted, because all of this was already possible before with workarounds (like intermediate `const fn`s) and the encoding/decoding already supports all the possible cases.
r? @eddyb
|
|
Speed up compilation of large constant arrays
This is a different approach to #51672 as suggested by @oli-obk. Rather
than write each repeated value one-by-one, we write the first one and
then copy its value directly into the remaining memory.
With this change, the [toy program](https://github.com/rust-lang/rust/blob/c2f4744d2db4e162df824d0bd0b093ba4b351545/src/test/run-pass/mir_heavy_promoted.rs) goes from 63 seconds to 19 seconds on my machine.
Edit: Inlining `Size::bytes()` saves an additional 6 seconds dropping the total time to 13 seconds on my machine.
Edit2: Now down to 2.8 seconds.
r? @oli-obk
cc @nnethercote @eddyb
|
|
|
|
Updated tests accordingly.
|
|
|
|
|
|
This saves 0.5 seconds on the test compilation.
|
|
This saves 4.5 seconds and takes the compile time down to 5.5 seconds.
|
|
Detect overflows of non u32 shifts
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This is a different approach to #51672 as suggested by @oli-obk. Rather
than write each repeated value one-by-one, we write the first one and
then copy its value directly into the remaining memory.
|
|
|
|
|
|
|
|
|
|
|
|
Fix the miri submodule
cc @bjorn3
r? @eddyb
|
|
|
|
|
|
|
