[stdlib] Add UInt __invert__

[martinvuyk]

Add UInt __invert__

[soraros]

I believe this won't compile if you add a test case as we can't convert a negative IntLiteral to UInt.

[helehex]

This looks good, although I wonder why __invert__() doesn't directly use the mlir ops. I noticed that with Int as well.
Maybe we should do something similar to Int.__neg__(), to be consistent, but it's not super important.

[martinvuyk]

Hi @helehex , well I think it's just an xor however you express it 🤷‍♂️ . I just want the functionality to do stuff with hashes

[helehex]

Yeah it's just a question about consistency. Hopefully this can get merged soon since it's been missing for a while.

[helehex]

Maybe you should add a test (even though int doesn't have one).

Also, if you use mlir ops, the implementation could be the same between Int and UInt, ie.

return __mlir_op.`index.xor`(
    value.value,
    __mlir_op.`index.constant`[value = __mlir_attr.`-1:index`](),
)

works for Uint and Int, the difference is just the implicit conversion on return.

[martinvuyk]

Maybe you should add a test (even though int doesn't have one).

Honestly this makes no difference, it's trivial. Inverting bits doesn't need a test IMO, that would be testing the CPU basically.

works for Uint and Int, the difference is just the implicit conversion on return.

When #3753 gets merged it will fail. And the code is already what gets added by the xor operation

@jackos can we merge this directly?

[helehex]

Both UInt and Int are really just wrappers around the mlir.index type, so i dont see why it would fail when that gets merged, theres no conversion between Int and UInt happening.

It may be trivial, but having a test is nice regardless to make sure it compiles, and to ensure nothing else breaks it down the line.

[helehex]

That being said, I'd be fine with it getting merged as is, it's just some suggestions.

[martinvuyk]

i dont see why it would fail when that gets merged, theres no conversion between Int and UInt happening.

yeah you're right I got confused and thought I changed the mlir index constructor in that PR but it was just the Int one.

It may be trivial, but having a test is nice regardless to make sure it compiles, and to ensure nothing else breaks it down the line.

Yeah it would be nice, I'm just a bit frustrated and I don't want to extend this PR further

[jackos]

When #3753 gets merged it will fail. And the code is already what gets added by the xor operation

Hi @martinvuyk that one is already failing a bunch of internal tests, I'll leave comments in that PR.

But this is separate I'll add a test on the internal PR and see if all the other internal tests pass.

[jackos]

!sync