Parser/printer fuzz tests for expressions

[xpyctumo]

Issue

Closes #1469

Checklist

• I have added tests to demonstrate the contribution is correctly implemented: this usually includes both positive and negative tests, showing the happy path(s) and featuring intentionally broken cases
• I have run all the tests locally and no test failure was reported
• I have run the linter, formatter and spellchecker
• I did not do unrelated and/or undiscussed refactorings

Plan

• AstExpression
  • AstOpBinary
  • AstOpUnary
  • AstConditional
  • AstMethodCall
  • AstFieldAccess
  • AstStaticCall
  • AstStructInstance
  • AstNumber
  • AstBoolean
  • AstId
  • AstInitOf
  • AstString
• AstLiteral
  • AstNumber
  • AstBoolean
  • AstNull
  • AstSimplifiedString
  • AstAddress
  • AstCell
  • AstSlice
  • AstCommentValue
  • AstStructValue

[anton-trunov]

when I see something like this, I immediately think of adding shrinking (fast-check should support it)

(+0b100100110001001100110111100100000101101111000011101011010101101101011110010000001000101100100000011000111001001110101001111011111100001101111110011000101010010001100000100100011010000100110011001111001000111001011101000100011011100111001110 ? 0xf39c6286c40970dcb2a321a1c21e4549de1a2d60bcc7ff84622639b35024a7f || 0o3235042541620525012122214562100130425412434124566713521630100545344175751456215504064 - -0o7777777777777777777777777777777777777777777777777777777777777777777777777777777777743 : 8 - (16227299991510006730850008471880976967479204885141379564359356953639308462371 == 0o5735742350164242162734544666035326212173453606274734532135112142107426251434140545063)) ? 0b10111100010010010001011110101011101010001000111101110001100011100001101000001011001111111101110100100011001000001001001111011110100011001100011010100111110010110110010011110110010001101000100111000101011110110110110010100100010011010011 + 0b11001101101101011111001101010011101111110011111110101001101100111000110011110110011010111001101011001111001111110001100110000010001001101011100010111101000010100000010001011100101110010100100101100101101110110110111100111100110111000101011111011001100010 + 26 + (0x157e944ffa07c17e8b222faf8abfab932cd54c213784eca386a32755e232289a ? 0o2667602156054031504566507661155302000265110317032415711565650770337656725250250767327 << 0o5520154115374334170135502317743632312724505264461136361671447006177506075556352660004 : 0o6624600205764760715715350617562272506065501073701250447411343437104466044353352053407) : 0b1

even shrinking integer literals would already help a lot here

[xpyctumo]

when I see something like this, I immediately think of adding shrinking (fast-check should support it)

(+0b100100110001001100110111100100000101101111000011101011010101101101011110010000001000101100100000011000111001001110101001111011111100001101111110011000101010010001100000100100011010000100110011001111001000111001011101000100011011100111001110 ? 0xf39c6286c40970dcb2a321a1c21e4549de1a2d60bcc7ff84622639b35024a7f || 0o3235042541620525012122214562100130425412434124566713521630100545344175751456215504064 - -0o7777777777777777777777777777777777777777777777777777777777777777777777777777777777743 : 8 - (16227299991510006730850008471880976967479204885141379564359356953639308462371 == 0o5735742350164242162734544666035326212173453606274734532135112142107426251434140545063)) ? 0b10111100010010010001011110101011101010001000111101110001100011100001101000001011001111111101110100100011001000001001001111011110100011001100011010100111110010110110010011110110010001101000100111000101011110110110110010100100010011010011 + 0b11001101101101011111001101010011101111110011111110101001101100111000110011110110011010111001101011001111001111110001100110000010001001101011100010111101000010100000010001011100101110010100100101100101101110110110111100111100110111000101011111011001100010 + 26 + (0x157e944ffa07c17e8b222faf8abfab932cd54c213784eca386a32755e232289a ? 0o2667602156054031504566507661155302000265110317032415711565650770337656725250250767327 << 0o5520154115374334170135502317743632312724505264461136361671447006177506075556352660004 : 0o6624600205764760715715350617562272506065501073701250447411343437104466044353352053407) : 0b1

even shrinking integer literals would already help a lot here

I'm thinking about that right now. It might become more user- friendly values

value: fc.bigInt({ min: -1_000_000_000n, max: 1_000_000_000n })

[anton-trunov]

@xpyctumo I took the liberty to merge the new parser into your branch and pushed a few fixes for the expressions generator too. Looks like the new parser fixed the issue with duplicated unary operators!

[anton-trunov]

Btw, these fuzzing-like tests should go into their own folder and only gets executed on a special request, separately from yarn tests.

[i582]

One of the example I get:

(+"").a(a{})

is not allowed because we need a capital initial letter for the types

Property failed after 5 tests
Seed: 1
Path: 4:0:0:0:0:1:0:0:0:1:1:1

[i582]

I think we definitely need diff when the trees differ, like here:

[i582]

I think supporting Slice might be too complicated at the moment since we use Slice type in AST node. We can skip it, fix all remaining issues and finally merge it

[i582]

One more example with wrong output:

0b1._("".a(), S_{oaFb3yD_: null})

0b1._("".a(), S_{oaFb3yD_: null})

[i582]

It's kinda bad code, but it can be a good starting point for nice and clear error output:

import {diffJson} from "diff";

fc.property(randomAstExpression(maxDepth), (generatedAst) => {
    const prettyBefore = prettyPrint(generatedAst);

    const parsedAst = parser.parseExpression(prettyBefore);
    const prettyAfter = prettyPrint(parsedAst);

    expect(prettyBefore).toBe(prettyAfter)

    const actual = eqExpressions(generatedAst, parsedAst);
    if (!actual) {
        const replacer = (key: string, value: unknown): unknown => {
            if (key === "id") return undefined;
            if (typeof value === "bigint") return value.toString();
            return value;
        };

        const left = JSON.stringify(sortObjectKeys(generatedAst), replacer, 4);
        const right = JSON.stringify(sortObjectKeys(parsedAst), replacer, 4);

        const differences = diffJson(left, right);

        const ConsoleColors = {
            added: "\x1b[32m",
            removed: "\x1b[31m",
            reset: "\x1b[0m",
        };

        differences.forEach(part => {
            const color = part.added
                ? ConsoleColors.added
                : part.removed
                    ? ConsoleColors.removed
                    : ConsoleColors.reset;

            process.stdout.write(color + part.value + ConsoleColors.reset);
        });

        process.stdout.write(`\n\n${prettyBefore}\n\n`);
        process.stdout.write(`${prettyAfter}\n\n`);
    }

    expect(actual).toBe(true);
}),

[xpyctumo]

I think supporting Slice might be too complicated at the moment since we use Slice type in AST node. We can skip it, fix all remaining issues and finally merge it

I decided to ignore the Address, Cell, and Slice generators until we solve their problem.

[xpyctumo]

Following generators are must be implemented. I leave them here to debug.

function randomAddress(): fc.Arbitrary<Address> {
    return fc.constant(
        address("EQCD39VS5jcptHL8vMjEXrzGaRcCVYto7HUn4bpAOg8xqB2N"), // TODO: use random address
    );
}

function randomCell(): fc.Arbitrary<Cell> {
    return fc.constant(beginCell().endCell()); // TODO: use random random here
}

function randomAstAddress(): fc.Arbitrary<A.AstAddress> {
    return dummyAstNode(
        fc.record({
            kind: fc.constant("address"),
            value: randomAddress(),
        }),
    );
}

function randomAstCell(): fc.Arbitrary<A.AstCell> {
    return dummyAstNode(
        fc.record({
            kind: fc.constant("cell"),
            value: randomCell(),
        }),
    );
}

function randomSlice(): fc.Arbitrary<Slice> {
    return fc.constant(beginCell().endCell().beginParse());
}

function randomAstSlice(): fc.Arbitrary<A.AstSlice> {
    return dummyAstNode(
        fc.record({
            kind: fc.constant("slice"),
            value: randomSlice(),
        }),
    );
}

[anton-trunov]

We need

• to introduce a command to run a sampler: yarn random-ast 42 would produce 42 random expressions and pretty print those in the terminal -- this is needed to understand what kind of expressions we actually produce
• to document this type of tests in CONTRIBUTING.md