From 08d6f2b872e0f5d48287be5e14448a45ada93066 Mon Sep 17 00:00:00 2001 From: "g. nicholas d'andrea" Date: Fri, 1 Sep 2023 19:48:56 -0400 Subject: [PATCH] Fix typos MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Kamil Śliwak --- docs/source/format.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/source/format.md b/docs/source/format.md index fbd640c0..6487b8e2 100644 --- a/docs/source/format.md +++ b/docs/source/format.md @@ -197,7 +197,7 @@ shape of the struct, and the different data locations of that struct are handled Reference types (that is, those types for which data location is relevant: `mapping`, `array`, `static_array`, or `struct`) do **not** explicitly include location information. Rather, the location specified in a `located` type propagates to any reference types - reachable along some path the type referenced in the `located` type's `type` field, + reachable along some path from the type referenced in the `located` type's `type` field, provided there is no intermediate `located` type field. What follows is an attempt at formal rigor. @@ -216,14 +216,14 @@ if a reference type `r` is encountered along two different paths with different then the values of type `r` have different locations, depending on the path. For example, consider the following type definition (using hypothetical syntax): -``` +```solidity struct MyStruct { OtherStruct f1; OtherStruct calldata f2; } ``` -Let the id the `OtherStruct` descriptor be `n`. +Let the id of the `OtherStruct` descriptor be `n`. Then the entry corresponding to `MyStruct` in the `types` array would be: ``` @@ -232,7 +232,7 @@ Then the entry corresponding to `MyStruct` in the `types` array would be: "sort": "struct", "declaration": /* ... */, "name": "MyStruct", - fields: [ + "fields": [ { "name": "f1", "type": n }, { "name": "f2", "type": { "sort": "located", @@ -266,13 +266,13 @@ The type descriptor `MyStruct memory` will be as follows: ...recalling that `m` is the id of the `MyStruct` definition above. -Given the definition of location propagation, the location of `x.f1` will `memory`, +Given the definition of location propagation, the location of `x.f1` will be `memory`, as that location has been propagated from the containing "located" type to the occurence of `n` in the description of the `f1` field. The location of `x.f2` will however be `calldata`, as the explicit `located` type encountered for `f2` overrides the location given in the outer located type. NB that the descriptions of the types for `f1` and `f2` both - ultimately reference the description `n` (i.e., `OtherStruct`) but the locations were different. + ultimately reference the description of `n` (i.e., `OtherStruct`) but the locations were different. **Discussion**: This design was chosen as it more closely mirrors the syntax and semantics @@ -282,8 +282,8 @@ That is, by themselves, type declarations do not (by default) have any informati As an added benefit, this encoding ensures there is a one-to-one mapping between Solidity type declarations and an entry in the `types` array, rather than _n_ different versions for _n_ different combinations of location combinations. -The downside of this choice is that not all entries in the `types` array have an unambigous interpretation, - only those that meet the criteria of well-located given above. +The downside of this choice is that not all entries in the `types` array have an unambiguous interpretation, + only those that meet the criteria of being well-located given above. #### Definition Scopes