Fix for Vyper immutables transformations

[marcocastignoli]

Vyper immutables transformation value is not limited of 32 bytes length. We should drop that part of the constraint in order to support Vyper contracts.

[kuzdogan]

Hmm right this is because we infer the immutables in Solidity from immutableReferences and each reference is a 32byte word, but with Vyper there's no such output and we extract it by looking at the end of the onchain runtime bytecode, right?

[marcocastignoli]

Hmm right this is because we infer the immutables in Solidity from immutableReferences and each reference is a 32byte word, but with Vyper there's no such output and we extract it by looking at the end of the onchain runtime bytecode, right?

Right 👍

[kuzdogan]

Makes sense for me.

Just, please update the live DB schemas too

Plus, tests are failing

[rimrakhimov]

Looks great for me! Just curious why did I put this 32 bytes condition in the first place :) Is it the case that Solidity immutable variables always are 32 bytes?

[marcocastignoli]

Looks great for me! Just curious why did I put this 32 bytes condition in the first place :) Is it the case that Solidity immutable variables always are 32 bytes?

I assumed it as true looking at that constraint

[kuzdogan]

Looks great for me! Just curious why did I put this 32 bytes condition in the first place :) Is it the case that Solidity immutable variables always are 32 bytes?

It seems so: "For these values, 32 bytes are reserved, even if they would fit in fewer bytes. Due to this, constant values can sometimes be cheaper than immutable values"

https://docs.soliditylang.org/en/latest/contracts.html#constant-and-immutable-state-variables

[kuzdogan]

@marcocastignoli This also makes me realize, one condition the optimizer sometimes puts constants in bytecode is when it reaches 32 bytes. Only then it probably makes sense costwise. This seems necessary but does not always lead to being written in the bytecode