JumpThreading: fix bitwise not on non-booleans

[clubby789]

Fixes #131195

Alternative to #131201

[rustbot]

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

[compiler-errors]

Thanks!

@bors r+

[bors]

📌 Commit fd35e82 has been approved by compiler-errors

It is now in the queue for this repository.

[compiler-errors]

Ok, well, this definitely causes a crash when building lock_api@0.4.12

@bors r-

Let's actually land #131201, which is a more conservative fix. Then we can work on improving the jumpthreading optimization :)

Since cjgillot authored the jump threading optimization (I think?) I can pass this off to them.

r? @cjgillot

[clubby789]

Looks like some miscompile in std 🤔 In my local testing I get println hanging on futex forever

[compiler-errors]

I am very curious to learn what is wrong with this PR :D

[bors]

☔ The latest upstream changes (presumably #131201) made this pull request unmergeable. Please resolve the merge conflicts.

[RalfJung]

@bors r-

[clubby789]

@rustbot ready
r? @RalfJung

[clubby789]

Threaded -> Option<()> through places where interp errors can happen. There's a few suspicious let Some(x) = .. else { return Some(()); } but I wanted to keep the behaviour for these as close to as the current

[RalfJung]

The unary_op(UnOp::Not part LGTM. But I'm not familiar with the jump threading parts so I'll bounce the review back for those structural changes.

r? @cjgillot

[cjgillot]

@clubby789 I'm not convinced by the second commit. If we get an interpreter error, we should only abort the current backwards walk, not the whole pass.

[cjgillot]

Threaded -> Option<()> through places where interp errors can happen. There's a few suspicious let Some(x) = .. else { return Some(()); } but I wanted to keep the behaviour for these as close to as the current

Do they actually cause a bug? Do you have a reproducer?

[clubby789]

iirc all instances that I looked at seemed to be fine, and changing them to return None instead caused issues

[cjgillot]

For the correctness in case of interpreter failure.
The correctness of the backtracking is ensured by mutated_statement clearing all relevant conditions. So if process_statement fails to insert a new condition, the obsolete ones are still removed from the state.
I'd rather have mutated_statement fixed if there is a bug, instead of an early exit contaminating everything.

[clubby789]

Sorry, I'm not quite sure what you mean here. Do you want additional changes?
I believe that all the instances where a None isn't propogated are intended functionality, not bugs

[bors]

☔ The latest upstream changes (presumably #132460) made this pull request unmergeable. Please resolve the merge conflicts.