feat: add more uint assertions

[odyslam]

• Fixes support more uint types in assert #165
• Adds foundry.toml to address latest allowed_paths error that originates from feat: add filesystem access permissions config for cheatcodes foundry#3007

[mds1]

I was going to comment on changing all the names to assertEq, then realized solc errors due to ambiguity. So then I deleted the 4 new assertions and changed these 4 tests to just use assertEq, and as expected solc upcasts them to uint256 using the existing assertions. So now I'm struggling to remember why we need these 😅

To clarify, if you remove the changes in Test.sol, all of these pass:

function testAssertions() public {
    assertEq(uint32(1), uint32(1));
    assertEq(uint64(1), uint64(1));
    assertEq(uint96(1), uint96(1));
    assertEq(uint128(1), uint128(1));
}

[odyslam]

While coding in 0.7.6, I have to explicitly cast the uint32 to uint256 to use assert.

[mds1]

Ahh got it. Interesting, so these are for < 0.8 and if you're on >= 0.8 they get upcasted automatically so you don't need them? If so sgtm, let's just add a comment explaining that so if we ever drop compatibility for <0.8 (#125) we remember to delete these overloads. cc @ZeroEkkusu for any other thoughts

[odyslam]

Didn't know that they are automatically upcasted in >0.8 . It's been so long in 0.7.0 land

[mds1]

Heh sorry to hear that 😛

[mds1]

This LGTM, @ZeroEkkusu would love a quick review to make sure there's nothing that affect v0.3 branch here / anything else blocking merge

[ZeroEkkusu]

Suggested change

	function assertUint128Eq(uint128 a, uint128 b) internal {
	assertEq(uint256(a), uint256(b));
	}
	function assertUint64Eq(uint64 a, uint64 b) internal {
	assertEq(uint256(a), uint256(b));
	}
	function assertUint96Eq(uint96 a, uint96 b) internal {
	assertEq(uint256(a), uint256(b));
	}
	function assertUint32Eq(uint32 a, uint32 b) internal {
	assertEq(uint256(a), uint256(b));
	}
	function assertEqUint(uint256 a, uint256 b) internal {
	assertEq(a, b);
	}

[odyslam]

Not sure what you suggest @ZeroEkkusu

[ZeroEkkusu]

Sorry, @odyslam, accidentally clicked Add single comment. I'll write up a full review real quick.

[ZeroEkkusu]

Suggested change

	function testAssertions() public {
	assertUint32Eq(uint32(1), uint32(1));
	assertUint64Eq(uint64(1), uint64(1));
	assertUint96Eq(uint96(1), uint96(1));
	assertUint128Eq(uint128(1), uint128(1));
	}

[ZeroEkkusu]

Solidity versions <=0.8.0 have a problem differentiating between uint and int overloaded functions when an argument is of type uintX, where X is less than 256. This does not apply to int arguments.

We are running into an issue because there are both assertEq(uint,uint) and assertEq(int,int), and not because the types do not get upscaled automatically.

I suggest we add a single function, assertEqUint(uint256,uint256), which will work for any uint type.

Let me know what you think.

[odyslam]

sounds good

[ZeroEkkusu]

LGTM. Thank you!

It is worth noting that we can also mix the types; e.g. this works:

assertEqUint(uint8(5), uint128(5));

One nit:

Tests should be in StdAssertions.t.sol (right now they're in StdCheats.t.sol).

If you want, I'll move the tests.