Incorrect order in YUL inliner

[TorstenStueber]

Given the following contract:

// SPDX-License-Identifier: MIT

pragma solidity >=0.8.0;

contract InnerContract {
    uint256 public innerConstructedStartTokenId;

    constructor() {
        innerConstructedStartTokenId = _startTokenId();
    }

    function _startTokenId() internal view virtual returns (uint256) {
        return 0;
    }
}

contract Test is InnerContract {
    uint256 public START_TOKEN_ID = 1;

    constructor() InnerContract() {
    }

    function _startTokenId() internal view virtual override returns (uint256) {
        return START_TOKEN_ID;
    }
}

The return value of the function innerConstructedStartTokenId of the contract Test is 0, although it should be 1.

This issue disappears when return START_TOKEN_ID; is replaced with return 1;.

It seems that this is due to the YUL inliner that violates the order of statements.

[TorstenStueber]

Here is another example that might be related to the same problem:

contract TestC {
    uint256 immutable z;
    uint s = 8;

    constructor(uint _val) {
        z = _val;
    }

    function fC() public returns (uint256) {
        return s;
    }
}

contract TestB is TestC {
    uint256 immutable y;

    constructor(uint _val) TestC(_val) {
        y = fC();
    }

    function fB() public returns (uint256) {
        return y;
    }
}

contract Test is TestC, TestB {
    uint256 immutable x;

    constructor() TestB(fC()) {
        x = z;
    }

    function f() public returns (uint256, uint256, uint256) {
        return (x, y, z);
    }
}

Calling f() on Test returns (0, 8, 0) instead of (8, 8, 8).

This seems to be the same well-known issue as the era compiler tests define this test for EVM with the return value (8, 8, 8) and for YUL with the return value (0, 8, 0)

[TorstenStueber]

This is still an issue with the latest version of pallet-revive (commit 736230e943c8fd47e9f993c969a6ec53ffdf0105) and resolc 0.4.1.

However, it works correctly with the EVM backend.

[xermicus]

Will be fixed in the compiler.

[pgherveou]

@xermicus this seems to still be an issue as of the current latest release

❯ resolc --version
Solidity frontend for the revive compiler version 0.6.0+commit.81ce306.llvm-18.1.8

[pgherveou]

@xermicus is that still the case in 1.0.0? or can it be closed?

[elle-j]

I looked into this and the Yul inliner is not actually the cause here (it preserves the same semantic ordering with and without optimization enabled). From solc's side, this is expected behavior when compiling via IR (as we do in resolc). Their docs describe the breaking changes ("the order of state variable initialization has changed in case of inheritance") when compared to their legacy codegen. TLDR (the difference):

• Legacy:
  • Runs two passes:
  • Pass 1: Initialize every contract's state variables from most base to most derived
  • Pass 2: Run every contract's constructor from most base to most derived
• viaIR:
  • Runs one pass:
  • Pass 1: For every contract from most base to most derived
    • (a) Initialize its state variables
    • (b) Run its constructor

So for the example in the issue description, when the InnerContract (most base) constructor runs, it calls _startTokenId() which returns 0 since START_TOKEN_ID at this point is 0 as initialization of Test's (most derived) state variables have not yet run.

They have some tests for this e.g. here (legacy) and here (viaIR).