[Bug-Candidate]: Variables referenced in assembly blocks may resolve incorrectly

[duckki]

Describe the issue:

There seems to be a bug in the IR generation for when variables with the same name are assigned in assembly in neighboring scopes.

Code example to reproduce the issue:

    function test_assigned_in_assembly_used_in_different_scopes(uint a, uint b) public view returns(uint) {
        if (a > 0) {
            uint v;
            uint w;
            assembly {
                v := mload(add(b, 0x20))
                w := byte(0, mload(add(b, 0x40)))
            }
            return test_used_in_assembly_assignment(v, w);
        } else {
            uint v;
            uint w;
            assembly {
                // The IRs assign to the variables `v` and `w`(defined in the then-clause)
                v := mload(add(b, 0x20))
                w := byte(0, mload(add(b, 0x40)))
            }
            // This call passes `v_scope0` and `w_scope1` correctly.
            return test_used_in_assembly_assignment(v, w);
        }
    }

Version:

0.9.2

Relevant log output:

IR:

	Function Test.test_assigned_in_assembly_used_in_different_scopes(uint256,uint256) (*)
		Expression: a > 0
		IRs:
			TMP_0(bool) = a > 0
			CONDITION TMP_0
		Expression: v = mload(uint256)(b + 0x20)
		IRs:
			TMP_1(uint256) = b + 32
			TMP_2(uint256) = SOLIDITY_CALL mload(uint256)(TMP_1)
			v(uint256) := TMP_2(uint256)
		Expression: w = byte(uint256,uint256)(0,mload(uint256)(b + 0x40))
		IRs:
			TMP_3(uint256) = b + 64
			TMP_4(uint256) = SOLIDITY_CALL mload(uint256)(TMP_3)
			TMP_5(uint256) = SOLIDITY_CALL byte(uint256,uint256)(0,TMP_4)
			w(uint256) := TMP_5(uint256)
		Expression: test_assigned_in_assembly_used_in_different_scopes(v,w)
		IRs:
			TMP_6(uint256) = INTERNAL_CALL, Test.test_assigned_in_assembly_used_in_different_scopes(uint256,uint256)(v,w)
			RETURN TMP_6
		Expression: v = mload(uint256)(b + 0x20)
		IRs:
			TMP_7(uint256) = b + 32
			TMP_8(uint256) = SOLIDITY_CALL mload(uint256)(TMP_7)
			v(uint256) := TMP_8(uint256)
		Expression: w = byte(uint256,uint256)(0,mload(uint256)(b + 0x40))
		IRs:
			TMP_9(uint256) = b + 64
			TMP_10(uint256) = SOLIDITY_CALL mload(uint256)(TMP_9)
			TMP_11(uint256) = SOLIDITY_CALL byte(uint256,uint256)(0,TMP_10)
			w(uint256) := TMP_11(uint256)
		Expression: test_assigned_in_assembly_used_in_different_scopes(v_scope_0,w_scope_1)
		IRs:
			TMP_12(uint256) = INTERNAL_CALL, Test.test_assigned_in_assembly_used_in_different_scopes(uint256,uint256)(v_scope_0,w_scope_1)
			RETURN TMP_12

[0xalpharush]

@bart1e Do you know if this is addressed by #1533

[bart1e]

@0xalpharush I don't think it is addressed by that PR, since it only changes the logic if variables are initialised in tuples (statements like (v, w) = f()). But I think that the problem here may be caused by a similar issue - probably a new Expression is generated from scratch that uses old variable names.