Miri sync #102573
Miri sync #102573
Conversation
readme: tag-gc tweaks r? `@saethlin` Is this option truly needed often enough that it should be in the 'common' section? If not I vote for moving it to the 2nd section. Also `10,000` is a confusing way to write numbers in an international context (in many languages, `,` in a number plays the role of the point in English number notation, so using a space or underscore is less likely to lead to confusion).
GC: factor out visiting all machine values `@saethlin` that is roughly what I had in mind. I think some parts of the state are skipped by the visitor. I listed the ones that I found in FIXMEs but I am not sure if that list is complete.
run all extern-so tests consistently without dependencies
Don't back up past the caller when looking for an FnEntry span Fixes rust-lang/miri#2536 This adds a fix for the logic as well as a regression test. In the new test `tests/fail/stacked_borrows/fnentry_invalidation2.rs`, before this PR, we display this diagnostic: ``` help: <3278> was later invalidated at offsets [0x0..0xc] by a Unique FnEntry retag --> tests/fail/stacked_borrows/fnentry_invalidation2.rs:13:5 | 13 | inner(&mut t); | ^^^^^^^^^^^^^ ``` Which is very misleading. It is not this call itself, but what happens within the call that invalidates the tag we want. With this PR, we get: ``` help: <2798> was later invalidated at offsets [0x0..0xc] by a Unique FnEntry retag inside this call --> tests/fail/stacked_borrows/fnentry_invalidation2.rs:20:13 | 20 | let _ = t.sli.as_mut_ptr(); | ^^^^^^^^^^^^^^^^^^ ``` Which is much better.
remove macOS work-around that is no longer needed Judging from actions/cache#403 it sounds like this work-around is not needed any more.
… all dependencies
CI: use cargo sparse registry CI spends a few minutes downloading the index so this could help.
Add flag to specify the number of cpus Apparently you can't rename a branch from github's website without it closing all your PRs with that branch. So this is just rust-lang#2545
|
The Miri subtree was changed cc @rust-lang/miri |
rust-highfive
added
the
S-waiting-on-review
|
Also this does not merge the entire recent Miri history, but only the parts before rust-lang/miri#2554 -- that PR will probably have to be edited out of the history via a force-push, and the rest then re-constructed by hand. |
|
I'll land rust-lang/miri#2566 once CI is green, so it's worth waiting for that IMO. I'll also use that to test re-syncing a bit. |
more details in stacked borrows tag tracking
Expand VisitMachineValues to cover more pointers in the interpreter Follow-on to rust-lang/miri#2559 This is making me want to write a proc macro 🤔 r? `@RalfJung`
|
Okay, syncing onto an already existing sync branch is not a thing -- josh will complain I don't quite understand why this is a problem, given that even when it succeeds the pushed tip does not contain a sync from the rustc repo, but 🤷 . We want to always use the 'remote counterpart does not exist yet, use |
|
There is something I don't quite understand though... josh decided to base this branch off of 8e3b9bc, which is quite a bit behind the current master. I did update my master branch to the latest one first so it could have picked a newer one. There seems to be nothing wrong with using that particular commit, but I'd like to understand why it didn't use the latest one... |
|
On the plus side, if I merge this with master, and then re-extract Miri, I do get something that is compatible with rust-lang/miri#2583. I get a commit with 2 parents: current miri master (the one I used as basis for this PR), and 338c50e which is the commit josh produced for the previous sync. So, it looks perfect. |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
looks unrelated |
|
The new diff lgtm. r=me unless you were still waiting on sth |
|
The base commit is a bit strange, but it doesn't affect the extracted history... so it's not relevant for roundtrips. (Future versions of josh making different choices here would not be a problem for us.) If we don't mind the rustc history graph becoming even more non-tree-like (the commit this is based on is not a bors-created merge commit, it's a commit from inside a PR), then I think we can land this. |
|
After reproducing the exact same commit with the alternative implementation of the required josh features from josh-project/josh#965, I am confident that this all holds together. @bors r=oli-obk |
|
@bors ping |
bors
added
S-waiting-on-bors
|
😪 I'm awake I'm awake |
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (27579a2): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Footnotes |
|
Good riddance, xargo, and thanks for all the fish. :) |
Miri sync This is a Miri sync created with my experimental fork of josh. We should probably not merge this yet, but we can use this to check if the sync looks the way it should. r? `@oli-obk`
This is a Miri sync created with my experimental fork of josh. We should probably not merge this yet, but we can use this to check if the sync looks the way it should.
r? @oli-obk