See Why did the default datatype layout change to
@layout comb ?
for background about this change.
Easy way out
To take the easy way out, set the
This will cause LIGO to undo the change, letting
@layout tree remain
This is only a temporary solution, intended to let people easily migrate to LIGO 1.0, which should be considered already deprecated as it will eventually be removed.
What's the problem?
If you do not take the easy way out, it's important to understand the problem.
In theory, it is possible that after upgrading to LIGO 1.0, your
contracts could compile successfully, your
ligo run test could pass,
and even "integration" tests (e.g. using a sandbox or test Tezos
network) could pass, yet after deployment you might still find that
your contracts are catastrophically broken.
This can happen if your contracts need to interact with other contracts, which are either:
- already deployed on mainnet, or
- compiled using an older version of LIGO, or
- compiled using a non-LIGO compiler, or
- implementing some standardized interface
If the compiled interface types (parameter, view, ...) for these
interactions change when you upgrade to LIGO 1.0, because you
previously (implicitly) used
@layout tree and now the types use
@layout comb, this will break compatibility, and the interactions
For example, consider the following test, involving communication
between two contracts over a parameter type
Note that this test will pass after upgrading to LIGO 1.0, because
when running the test, both
Bar use the
comb layout for
the parameter type
foo. However, if there is already a
contract deployed on mainnet, e.g. compiled using an older LIGO
version, then a newly compiled
Bar contract will be unable to
communicate with it, because the new
foo type will be incompatible!
So, in order to test that your contracts still work correctly, you must either manually check that the interface types have changed, or test interactions with the actual contracts you will need to interact with.
In particular, if you are testing compatibility for interactions, you
should NOT only test interactions against contracts compiled using
LIGO 1.0, e.g. using
ligo test, because those contracts will use the
new layout too!
If, on the other hand, you will deploy a new set of contracts which only interact amongst themselves, then you have nothing to worry about. It is only interactions with pre-existing or standardized contracts that can cause trouble.
How to deal with compatibility problems?
If you have compatibility problems like this, and you don't take the
easy way out with
LIGO_LEGACY_LAYOUT_TREE, you might need to switch
some types back to the tree layout.
Here are some examples of how to do that:
Type errors from layouts
In some cases, you may get type errors due to mismatched type layouts.
Here is an example. Before LIGO 1.0, this code worked OK:
However, as of LIGO 1.0, this example gives a type error:
The reason for this is that in the old
tree layout, the fields were sorted alphabetically, but in the
comb layout they are taken in the declared order.
You can fix this problem either by switching back to the
tree layout (see the previous section) or by writing the fields in a consistent order.