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 LIGO_LEGACY_LAYOUT_TREE
environment variable:
This will cause LIGO to undo the change, letting @layout tree
remain
the default.
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
will fail.
For example, consider the following test, involving communication
between two contracts over a parameter type foo
:
Note that this test will pass after upgrading to LIGO 1.0, because
when running the test, both Foo
and Bar
use the comb
layout for
the parameter type foo
. However, if there is already a Foo
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.