execution/abi: fix regex submatch for parsing variable size in types

[Sahil-4555]

This request fixes a parsing issue in the ABI package that occurs when evaluating types with multi-dimensional sizes. Previously, the regular expression used the wrong capture group when parsing the type string. For types such as fixed128x18, the code incorrectly captured the entire suffix "128x18" instead of just the leading number "128". This caused an invalid syntax error when the application attempted to parse that combined string as an integer.

By updating the regex submatch index, the parser now correctly isolates the first numeric value so it can be evaluated properly. Along with this fix, a regression test has been added to ensure that unsupported fixed-point types correctly return an "unsupported arg type" error rather than failing unexpectedly during the size calculation process.

[Copilot]

Pull request overview

Fixes ABI type parsing for fixed-point-like type strings where the regex submatch used to compute the first numeric size was incorrect, preventing the intended “unsupported arg type” path from being reached.

Changes:

• Correct NewType to parse the first numeric size from parsedType[3] (not parsedType[2]) when the matched suffix can include an x... component.
• Add a regression test covering fixed128x18 / ufixed256x10 to ensure the bug doesn’t reappear.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
execution/abi/type.go	Fixes the submatch index used for varSize parsing in NewType.
execution/abi/type_test.go	Adds a regression test to guard against the prior size-parsing failure mode for fixed-point-like types.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[yperbasis]

Copilot already flagged this and I agree: the regression test only asserts the error string does not contain "error parsing variable size". That's a weak negative assertion — any
other failure mode (e.g. an "invalid type" error from a future regex change) would still pass the test.

The simplest tightening matches what the PR description claims:

if !strings.Contains(err.Error(), "unsupported arg type") {
t.Fatalf("type %q: got %v; want error containing %q", s, err, "unsupported arg type")
}