fixed MSTORE typo in libevmasm tests

[Saw-mon-and-Natalie]

No description provided.

[github-actions]

Thank you for your contribution to the Solidity compiler! A team member will follow up shortly.

If you haven't read our contributing guidelines and our review checklist before, please do it now, this makes the reviewing process and accepting your contribution smoother.

If you have any questions or need our help, feel free to post them in the PR or talk to us directly on the #solidity-dev channel on Matrix.

[Saw-mon-and-Natalie]

@christianparpart , what are the assumption on the stack before the DUP opcodes? What are we dupping and is <n> supposed to be the immutable value?

this was introduced in:

• b1dd0d0

[Saw-mon-and-Natalie]

Based on the BOOST_AUTO_TEST_CASE(immutable) it seems like on top of the stack we have:

<CODE_OFFSET> <IMMUTABLE_VALUE>

and <n>. represents the relative offset of the immutable position to the code offset.

Perhaps the assumptions about the stack should be documented and wether we are always using DUP2 DUP2.

[Saw-mon-and-Natalie]

snippet from Assembly::assemble():

case AssignImmutable:
{
	// Expect 2 elements on stack (source, dest_base)
	auto const& offsets = immutableReferencesBySub[i.data()].second;
	for (size_t i = 0; i < offsets.size(); ++i)
	{
		if (i != offsets.size() - 1)
		{
			ret.bytecode.push_back(uint8_t(Instruction::DUP2));
			ret.bytecode.push_back(uint8_t(Instruction::DUP2));
		}
		// TODO: should we make use of the constant optimizer methods for pushing the offsets?
		bytes offsetBytes = toCompactBigEndian(u256(offsets[i]));
		ret.bytecode.push_back(static_cast<uint8_t>(pushInstruction(static_cast<unsigned>(offsetBytes.size()))));
		ret.bytecode += offsetBytes;
		ret.bytecode.push_back(uint8_t(Instruction::ADD));
		ret.bytecode.push_back(uint8_t(Instruction::MSTORE));
	}
	if (offsets.empty())
	{
		ret.bytecode.push_back(uint8_t(Instruction::POP));
		ret.bytecode.push_back(uint8_t(Instruction::POP));
	}
	immutableReferencesBySub.erase(i.data());
	break;
}

[matheusaaguiar]

Perhaps the assumptions about the stack should be documented and wether we are always using DUP2 DUP2.

Maybe that's a good idea, but then it would be better if done in other PR.

[matheusaaguiar]

@Saw-mon-and-Natalie , thanks for the PR.
Let's stick only with the fixed typos on this one.
Can you rebase, please?

[matheusaaguiar]

Perhaps the assumptions about the stack should be documented and wether we are always using DUP2 DUP2.

Maybe that's a good idea, but then it would be better if done in other PR.