[Aleo ins parser] Fix array type anomaly. #2017
Conversation
| @@ -42,8 +42,6 @@ impl<N: Network> Parser for ArrayType<N> { | |||
| Ok((string, length)) | |||
| } | |||
|
|
|||
| // Parse the whitespace and comments from the string. | |||
| let (string, _) = Sanitizer::parse(string)?; | |||
There was a problem hiding this comment.
I think this parse is justified. At the least we should have parse_whitespaces.
There was a problem hiding this comment.
This array type parser is called by the plaintext type parser, which expects whitespace to have been skipped over already: the other two alternative parsers for plaintext type, namely literal type and identifier, do not skip over whitespace.
This is an instance of a general pattern in the Aleo instructions parser:
- Some (larger) constructs are parsed by first skipping over white space (and sometimes also comments).
- Other (smaller) constructs are parsed without any such initial skipping, i.e. they are expected to start right there. Their callers skip white space already.
Plaintext types, including array types, belong to the second group of constructs above.
There was a problem hiding this comment.
I see your perspective, we should make sure its parent callers have some notion of parse_whitespace since we don't invoke string.trim() before calling the parser.
There was a problem hiding this comment.
Yes, definitely. I believe that to be the case. I don't have a formal proof yet, but here's an argument. As you may know, I've derived the ABNF grammar of Aleo instructions directly from the parser. So under the (good) assumption that the grammar is consistent with the parser, we can see the following in the grammar:
- Every occurrence of
plaintext-typenot at the start of the right side of a rule is preceded byws, which corresponds toSanitizer::parse_whitespaces. plainttext-typeoccurs at the start of the right sides ofvalue-type,mapping-type,finalize-type, andentry-type.- We repeat the same argument for
value-type, ...,entry-type, recursively, and find that there is always a precedingws.
(That was actually a sketch of a formal proof.)
Fixes #2016.