Remove the wrong codegen assumption that a conversion between non-byte calldata arrays can never happen

[rodiazet]

This PR allows generating a array conversion code for the same types array. It was mentioned already in #10893 (comment) that is should be allowed for equal types but it was not added eventually. Not sure why.

Fixes: #16066

[stackenbotten3000]

There was an error when running chk_coding_style for commit fad4d9618d66a75a209afe2111823375846477fa:

Error: Trailing whitespace found:
test/libsolidity/semanticTests/array/conversion_of_ordinary_types_array.sol:5:    } 

Please check that your changes are working as intended.

[cameel]

Please add tests for slices and static arrays as well. At least the latter also trigger the ICE.

contract C {
    function f(uint[] calldata a) public {
        (uint[] calldata b, ) = true ? (a[:], 0) : (a[0:1], 0);
    }
}

contract C {
    function f(uint[3] calldata a) public {
        (uint[3] calldata b, ) = true ? (a, 0) : (a, 0);
    }
}

Also a mix of arrays and slices ((a, 0) : (a[:], 0)).

[cameel]

I'd keep the if here. This is usually more readable than the negation you have to add to incorporate it into condition and our asserts are not debug anyway (we don't remove them from release builds).

[cameel]

Suggested change

	ss[0].ns = new N[](1);
	ss[0].ns[0].addr = address(this);
	ss[0].ns[0].data = "abdeff00";
	ss[0].data = "abdeff";
	ss[0].ns = new N[](1);
	ss[0].ns[0].addr = address(this);
	ss[0].ns[0].data = "abdeff00";
	ss[0].data = "abdeff";

[cameel]

It would be better if the expectations were just formatted in a way that makes it more obvious at a glance that they're correct.

For example you could format strings as actual strings (soltest does accept those). I'd also use some regular-looking hard-coded addresses instead of things like tx.origin and msg.sender or address(this). Those are pretty noisy-looking, not easy to fish out visually. For fields with lots of zeros you can either use hex strings (those are not automatically padded to 32 bytes unlike integers) or left()/right() helpers to pad a shorter value to 32 bytes. I also usually use hex for offsets but decimals for sizes, which makes encoding a bit easier to decode visually.

Having to read it very carefully quickly gets tedious when reading a lot of tests. Overall we should try a bit harder optimize expectations for being able to quickly verifying them.

[cameel]

Can you check #16066 (comment)? We should really check why something like true ? (a, true) : (a, true) does not trigger this bug. This may mean that either we're not doing an array conversion in some case were we need it or that we shouldn't be doing it in the true ? (a, 0) : (a, 0) case.

[cameel]

TBH I'd have no idea what this test does just from the current name. What do you mean by "ordinary types"?

This should be way more specific:
conversion_of_ordinary_types_array.sol -> non_byte_calldata_array_conversion_in_ternary_with_tuple_operands.sol

[cameel]

I'd put this bit in a separate file. It's independent of the larger case, and when one of those fails it's usually nicer to have a smaller one that's easier to understand to debug.

[cameel]

The PR is missing a changelog entry.