Add unsigned integer support

[JoshuaGlaZ]

Summary

The astx library already defines unsigned integer types (UInt8, UInt16, UInt32, UInt64, UInt128) and their corresponding literal nodes but the IRx backend has no visitor methods for any of these nodes. As a result, unsigned integers are currently unsupported in code generation. Also, llvmlite already supports unsigned instructions (udiv, urem, icmp_unsigned) and since LLVM has no distinct unsigned types, UInt8-UInt128 map to the same ir.IntType(N) as their signed counterparts.

If maintainers are open to it, I'd be happy to work on a PR for this.

Additional Information

Code of Conduct

• I agree to follow the Code of Conduct

[Jaskirat-s7]

Hey! I'd like to work on this. I've already implemented visitor methods for all five unsigned integer literal types (LiteralUInt8, LiteralUInt16, LiteralUInt32, LiteralUInt64, LiteralUInt128) in LLVMLiteIRVisitor, along with unit tests.

Since LLVM's ir.IntType(N) is sign-agnostic, the unsigned literals map to the same ir.IntType as their signed counterparts — signedness is only relevant at the instruction level (udiv, urem, icmp_unsigned).

All tests and pre-commit checks pass ✅ (screenshot attached). PR incoming!

[yuvimittal]

@JoshuaGlaZ @Jaskirat-s7 I understand that both of you are eager to work on this issue, but currently there are two PRs raised for the same one. Could you please coordinate between yourselves and decide how to proceed? If one of you hasn’t progressed too far yet, it might be better to close the PR and pick up a different issue to work on.

[Jaskirat-s7]

Hi @yuvimittal and @JoshuaGlaZ!

I completely understand. Just to give a quick update on my end: The implementation in PR #187 is fully complete. I've added the https://github.com/dispatch lowering for all 5 unsigned integer types (LiteralUInt8, LiteralUInt16, LiteralUInt32, LiteralUInt64, LiteralUInt128) and mapped them successfully to their respective llvmlite.ir.IntType constants.

I've also written a comprehensive test suite (tests/test_unsigned_int.py with ~140 lines of tests) covering base functionality, zero-value boundaries, and maximum bounds for all widths, and all CI/CD pipelines (ruff, douki, mypy, pytest) are passing green.

Since the PR is fully baked and the tests are comprehensive, I'd love to see it reviewed if possible! But I am happy to defer to whatever the maintainers think is best for the project.

[yuvimittal]

@Jaskirat-s7 What I meant is that before starting work on an issue, it’s a good idea to check if someone else is already working on it or if the issue was raised by someone intending to work on it. In this case, @JoshuaGlaZ had opened the issue and has also submitted a PR for it, so there ended up being parallel work on the same thing.

[Jaskirat-s7]

Hi @yuvimittal, that makes total sense! I didn't realize @JoshuaGlaZ was the original author of the issue and had planned to PR it as well. Thanks for clarifying the context!
@JoshuaGlaZ, since you opened the initial issue, it's completely fair that you take the lead on this! i will be closing my PR (#187) so that we can move forward with yours. If there are any test cases or mappings from my PR that you'd like to pull into yours (like the boundary checks in test_unsigned_int.py), please feel free to grab them.
Let me know if you want me to go ahead and close mine! I'll pick up a different issue from the backlog in the meantime.

[JoshuaGlaZ]

@yuvimittal I've opened a new PR with the updated changes for unsigned integer operands to wrap up the unsigned integer support.