fix: ensure that tuple variable's types belong to the Type class

[kevinclancy]

Notes

The "types" of the tuple variable generated from a struct-destructuring assignment are actually strings. For example, the tuple variable generated from the following program has a list of strings instead of a list of types:

pragma solidity ^0.8.19;

contract OtherContract {
    struct S {
        uint x;
        uint y;
    }

    mapping(uint => S) public m;
}

contract Test {
    OtherContract c;
    function test() external {
        (uint x, uint y) = c.m(0);
    }
}

Struct destructuring is implemented in a function called _convert_to_structure_to_list in convert.py. When it encounters structure types, it destructures them and flattens the result into the outer structure's list. When it encounters elementary types, it should include the type in the list, but instead it includes the type's type field, which is a string. This PR fixes that by returning the ElementaryType instead of its type field.

Testing

• Run make test and verify that all tests succeed
• Run ./evaluate.sh run 100 in tool-eval.sh and verify that all projects succeed

Related Issue

https://github.com/CertiKProject/slither-task/issues/508

[duckki]

I think the root cause is the Function.return_type property is not returning a List[Type] (typing error). In fact, any LocalVariable has a string literal type value would be wrong, in the first place.
How about intercepting earlier like in Variable.type or Function.return_type ?

[kevinclancy]

Good call. I have fixed the issue. That makes me wonder what root cause issue the current implementation of set_type is hiding:

    def set_type(self, t: Optional[Union[List, Type, str]]) -> None:
        if isinstance(t, str):
            self._type = ElementaryType(t)
            return
        assert isinstance(t, (Type, list)) or t is None
        self._type = t

[kevinclancy]

I just realized that this fix doesn't handle structs with nested fields of type Contract and Enum correctly.

[duckki]

Looks good!
We should contribute this to upstream.