[Yul] Yul objects parser

[chriseth]

Parser for yul objects. Backwards-compatible in that it generates a yul object with only code if it is given only code.

Also modifies the assembly stack and the solc --assemble functionality to use yul objects.

What is still missing (different PR):

• implement code generator changes
• add yul functions to access objects

[axic]

Can you split the specification change out?

[chriseth]

Factored out: #5428

[codecov]

Codecov Report

Merging #5358 into develop will increase coverage by 0.02%.
The diff coverage is 89.41%.

@@             Coverage Diff             @@
##           develop    #5358      +/-   ##
===========================================
+ Coverage    88.17%   88.19%   +0.02%     
===========================================
  Files          314      319       +5     
  Lines        31497    31649     +152     
  Branches      3775     3791      +16     
===========================================
+ Hits         27773    27914     +141     
- Misses        2457     2459       +2     
- Partials      1267     1276       +9

Flag	Coverage Δ
#all	88.19% <89.41%> (+0.02%)	⬆️
#syntax	28.97% <9.41%> (-0.09%)	⬇️

[chriseth]

Question: Is the order of sub-objects relevant? Should we retain it? Currently, the printer sorts the sub objects according to the YulString sorting order, which is bad.

We should either sort the sub objects by binary string order or retain the order.

Any opinions?

[axic]

I don't think the ordering should matter, but I can definitely see that being expected from others, so I would suggest to keep the order it was parsed or the order it was inserted into the AST.

[chriseth]

Yep, sounds good! This probably requires some modifications in YulObject. Will work on that next week.

[chriseth]

This is the default name for the object if only code is given. Any better ideas?

[leonardoalt]

I think this name is fine.

[leonardoalt]

I would suggest that the names of objects and data could be either string literals or identifiers.

[leonardoalt]

Not used

[chriseth]

About using literal strings or identifiers: I would want to avoid using actual identifiers in code (i.e. in mstore(0, datasize("subContract"))) because then we would have different scoping rules for things that otherwise look identical - it should just be fully opaque for things like the optimizer.

If we agree on that, then I think it also makes sense to use the syntax

object "objectName" { ... }

instead of

object objectName { ... }

Edit: Replaced "literals" by "identifiers"

[chriseth]

Will extract the tests into isoltest.

[leonardoalt]

Wait, you said you do not want to use literals in the code (e.g. "subContract"), but that it makes sense then to use the syntax object "objectName". I'm a bit confused.

[leonardoalt]

The grammar says that code is optional, but the parser returns an error if it's not there. By looking at the rest of the code, I assume the grammar is wrong.

[chriseth]

Ah, I did not remember that! I guess it does not make too much sense to have objects without code. If you really want to have an object without code, you can also use empty code.

Another thing I noticed is that according to the grammar, the top level object has no name. This is a mistake, I would say.

[leonardoalt]

I think this name is fine.

[chriseth]

@leonardoalt sorry, I meant to write "identifier" instead of "literal" - updated my comment, please take a look.

[chriseth]

In summary, I would propose to change the Yul grammar such that:

• there is no distinction between top-level and general object (i.e. also the top-level object has to be name)
• code is not optional

[leonardoalt]

@chriseth I agree with your literal/identifier and grammar points.

[chriseth]

OK, then I'll merge this and update the grammar in another PR.

[chriseth]

Actually, let me make an addition to the changelog, because the --assembly output changed.

[chriseth]

Grammar change is here: #5524