Array of `super` is still accepted as a type in some contexts and triggers and ICE in `abi.decode()`

[Jizhou-Chen]

Description

Error:

Internal compiler error:
/solidity/libsolidity/ast/Types.cpp(1982): Throw in function virtual solidity::frontend::TypeResult solidity::frontend::ArrayType::interfaceType(bool) const
Dynamic exception type: boost::wrapexcept<solidity::langutil::InternalCompilerError>
std::exception::what: Expected detailed error message!
[solidity::util::tag_comment*] = Expected detailed error message!

Note: This bug was reported in #8280 and marked as completed in 2020. However, it still exists in the latest release (v0.8.28), hence this report.

Environment

• Compiler version: Version: 0.8.28-develop.2025.1.19+commit.7893614a.mod.Linux.g++
• Compilation pipeline (legacy, IR, EOF):
• Target EVM version (as per compiler settings):
• Framework/IDE (e.g. Foundry, Hardhat, Remix):
• EVM execution environment / backend / blockchain client:
• Operating system: Ubuntu 22.04

Steps to Reproduce

poc.sol (fuzzer-generated):

contract test {
    struct S {
        uint8[] a;
        string[2] b;
    }

    S[][] s1;
    S[][1] s2;
    S[1][] s3;

    function f(bytes calldata data)
        external
        pure
        returns (uint256[2][3] memory)
    {
        return abi.decode(data, (super[3]));
    }

    function test2(S[][1] memory _a) public returns (S[][1] memory) {}

    function f(uint[2] memory) public pure {}
}

To reproduce:
solc --bin -o poc poc.sol

[cameel]

Simplified repro:

contract C {
    function f() external {
        abi.decode("", (super[0]));
    }
}

A related bug is that arrays of super seem to be recognized as a valid type in some contexts:

contract C {
    function f() external {
        super[3] memory x; // Error: Name has to refer to a user-defined type.
        super[3];          // OK: type(contract super C[3] memory)
        super[3][3];       // OK: type(contract super C[3] memory[3] memory)
        super[0];          // OK: type(contract super C[0] memory)
    }

    type T1 is super;      // Error: Name has to refer to a user-defined type.
    type T2 is super[3];   // Error: Name has to refer to a user-defined type.

    error E1(super x);     // Error: Name has to refer to a user-defined type.
    error E2(super[3] x);  // Error: Name has to refer to a user-defined type.
}

This is probably also what allows this ICE to happen in the first place. We're likely not expecting this type to get as far in analysis as it does.

Must be a leftover from #7744/#10029.