Reject CALOAD on non-char arrays in structural verification

[rootvector2]

InstConstraintVisitor.visitCALOAD only checks that the arrayref is some array, never that its component type is char, so Pass3b structural verification accepts caload on any array such as an int[] or a reference array like String[]. ExecutionVisitor.visitCALOAD then models the loaded value as int, so a reference read through caload is type confused as an int while the class still verifies. Found by comparing visitCALOAD against its store counterpart visitCASTORE just below it, which does check char.

Add the same component-type check that visitCASTORE uses so the constraint sits next to the other array-access checks in the structural pass. TestArrayAccess06 applies caload to an int[] and asserts verification rejects it.

• Read the contribution guidelines for this project.
• Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
• I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
• Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
• Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Each commit in the pull request should have a meaningful subject line and body.

[garydgregory]

Thank you @rootvector2 ; merged 🚀 Do you see similar issues with other *LOAD or *STORE methods?

[rootvector2]

checked the rest and they're all covered now. the int/long/float/double/short load/store family verifies its element type via isElementType since #520, BALOAD/BASTORE check byte/boolean, and AALOAD/AASTORE check for a ReferenceType element. caload was the only one with no component check at all. thanks for merging this.

[garydgregory]

Thank you for checking @rootvector2
Do we have tests that cover all the cases you mention?

[rootvector2]

partially. TestArrayAccess05 covers iaload (the #520 path) and TestArrayAccess06 covers caload. TestArrayAccess03 and the TestArrayAccess04* family exercise aastore (on a non-array ref and with primitive values into an Object[]). there are no negative tests yet for castore, baload/bastore, saload, aaload, or the remaining primitive load/store pairs like laload/lastore. I can put together a follow-up PR adding those if you want.

[garydgregory]

@rootvector2 A follow up PR with the missing tests would be great. It will be nice to achieve parity in avoiding regressions. TY!

[rootvector2]

opened #524 with the missing tests. one parameterized creator covers aaload, aastore, castore, baload/bastore, saload/sastore, iastore and the long/float/double pairs, and I checked each case fails in pass 3b on the component type constraint rather than in an earlier pass.