ISubParserV1

Git Source

Handle parsing some data on behalf of a parser. The structure and meaning of the data is entirely up to the parser, the compatibility version indicates a unique ID for a particular parseble data convention.

function subParse(bytes32 compatibility, bytes calldata data)
    external
    pure
    returns (bool success, bytes calldata bytecode, uint256[] calldata constants);

Parameters

Name	Type	Description
`compatibility`	`bytes32`	The compatibility version of the data to parse. The sub parser is free to handle this however it likes, but it MUST revert if it is unsure how to handle the data. E.g. the sub parser MAY revert any compatibility version that is not an exact match to a singular known constant, or it may attempt to support several versions.
`data`	`bytes`	The data to parse. The main parser will provide arbitrary data that is expected to match the conventions implied by the compatibility version. As sub parsing is a read only operation, any corrupt data could only possibly harm the main parser, which in turn should be parsing as a read only operation to protect itself from malicious inputs.

Returns

Name	Type	Description
`success`	`bool`	The first return value is a success flag, yet the sub parser MAY REVERT under certain conditions. It is important to know when to revert and when to return false. The general rule is that if the inputs are understood by the subparser, and look wrong to the subparser, then the subparser MUST revert. If the inputs are not understood by the subparser, it MUST NOT revert, as it is not in a position to know if the inputs are wrong or not, and there is very likely some other subparser known to the main parser that can handle the data as a fallback. For example, the following situations are expected to revert: - The compatibility ID is not supported by the sub parser. Every sub parser knows what it is compatible with, so it is safe to revert anything incompatible. - The data parses to something the sub parser knows how to handle, but the data is malformed in some way. For example, the sub parser knows the word it is parsing, but perhaps some associated data such as the constants height is out of a valid range. Similarly, the following situations are expected to return false and not revert: - The compatibility ID is supported by the sub parser, and the data appears to have the correct structure, but there are no recognized words in the data. This MUST NOT revert, as some other sub parser MAY recognize the word and handle it as a fallback.
`bytecode`	`bytes`	If successful, the second return value is the bytecode that the subparser has generated. The main parser is expected to merge this into the main bytecode as-is, so it MUST match main parser behaviour as per the compatibility conventions. If unsuccessful, a zero length byte array.
`constants`	`uint256[]`	If successful, and the generated bytecode implies additions to the constants array, the third return value is the constants that the subparser has generated. The main parser is expected to merge this into the main constants array as-is. If the parsing is unsuccessful, or the generated bytecode does not require any new constants, a zero length array.

ISubParserV1

Functions

subParse