move CTFE engine snapshot state out of miri engine into CTFE machine instance#54380
move CTFE engine snapshot state out of miri engine into CTFE machine instance#54380bors merged 7 commits intorust-lang:masterfrom
Conversation
|
(rust_highfive has picked a reviewer for you, use r? to override) |
There was a problem hiding this comment.
This is the part I am least certain about: This is the only caller of eval_promoted, and it now operates in a new EvalContext instead of doing horrible things to the existing one. Seems to work fine...
e235795 to
0958472
Compare
0958472 to
b1453dd
Compare
…ime order in ConstPropagator consistent with Memory
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
|
Eh, what? I compiled this locally... EDIT: Funny, this compiled in stage 2 but not stage 1. |
|
r? @eddyb |
| hcx: &mut StableHashingContext<'b>, | ||
| hasher: &mut StableHasher<W>) | ||
| { | ||
| // Not hashing memory: Avoid hashing memory all the time during execution |
There was a problem hiding this comment.
You only need HashStable if you're putting these snapshots through queries (because incremental needs to save/reload them) - is that the case?
There was a problem hiding this comment.
| stmt: usize, | ||
| } | ||
|
|
||
| // Not using the macro because that does not support types depending on 'tcx |
There was a problem hiding this comment.
That's surprising, I'd expect it's because 'mir, not 'tcx - lots of types depend on 'tcx.
There was a problem hiding this comment.
Ah no the problem is that it doesn't support things depending on TWO lifetimes.
Just one lifetime and any number of types.
When can we #[derive] this? :D
There was a problem hiding this comment.
When can we
#[derive]this? :D
#49219, which is lower priority than the edition :(
|
@bors r+ |
|
📌 Commit 8e74ee0 has been approved by |
move CTFE engine snapshot state out of miri engine into CTFE machine instance It still lives in the `interpret` module as it needs access to all sorts of private stuff. Also rename a thing to make @eddyb happy :D The goal was not to change any behavior.
|
☀️ Test successful - status-appveyor, status-travis |
Tested on commit rust-lang/rust@be91c35. Direct link to PR: <rust-lang/rust#54380> 💔 miri on windows: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra). 💔 miri on linux: test-pass → build-fail (cc @oli-obk @RalfJung @eddyb, @rust-lang/infra).
miri engine: basic support for pointer provenance tracking This enriches pointers with a new member, `tag`, that can be used to do provenance tracking. This is a new type parameter that propagates up through everything. It defaults to `()` (no tag), which is also the value used by CTFE -- but miri will use another type. The only actually interesting piece here, I think, is what I had to do in the memory's `get`. The problem is that `tcx` (storing the allocations for statics) uses `()` for provenance information. But the machine might need another tag. The machine has a function to do the conversion, but if a conversion actually happened, we need to store the result of this *somewhere* -- we cannot return a pointer into `tcx` as we usually would. So I introduced `MonoHashMap` which uses `RefCell` to be able to insert new entries even when we just have a shared ref. However, it is important that we can also return shared refs into the map without holding the `RefCell` opan. This is achieved by boxing the values stored in the map, so their addresses remain stable even when the map's table gets reallocated. This is all implemented in `mono_hash_map.rs`. NOTE: This PR also contains the commits from #54380 (comment). Only the [last two commits](https://github.com/rust-lang/rust/pull/54461/files/8e74ee0998a5b11f28d61600dbb881c7168a4a40..HEAD) are new.
It still lives in the
interpretmodule as it needs access to all sorts of private stuff. Also rename a thing to make @eddyb happy :DThe goal was not to change any behavior.