From 3e674f78f4c519291be29ecb260cc0e73c08828e Mon Sep 17 00:00:00 2001 From: SkymanOne Date: Mon, 28 Aug 2023 13:16:41 +0100 Subject: [PATCH] fix spelling --- integration-tests/upgradeable-contracts/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/integration-tests/upgradeable-contracts/README.md b/integration-tests/upgradeable-contracts/README.md index 5f7f3d351f..b6fb8ca298 100644 --- a/integration-tests/upgradeable-contracts/README.md +++ b/integration-tests/upgradeable-contracts/README.md @@ -24,10 +24,10 @@ Similarly, the storage compatibility issue is also applicable here. However, there are certain nuances associated with using `delegate_call`. First of all, as demonstrated in the example, if the delegated code intends to mutate the caller's storage, -a developer needs to be mindful. If the delegated code modifies layoutful storage +a developer needs to be mindful. If the delegated code modifies layout-full storage (i.e. it contains at least non-`Lazy`, non-`Mapping` field), the `.set_tail_call(true)` flag of `CallFlags` needs to be specified and the storage layouts must match. This is due to the way ink! execution call stack is operated -(see [StackExchange Answer](https://substrate.stackexchange.com/a/3352/3098) for more explanation). +(see [Stack Exchange Answer](https://substrate.stackexchange.com/a/3352/3098) for more explanation). If the delegated code only modifies `Lazy` or `Mapping` field, the keys must be identical and `.set_tail_call(true)` is optional. This is because `Lazy` and `Mapping` interact with the storage directly instead of loading and flushing storage states.