| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172 |
- # Expected results for tests/fixtures/*.pas - one line per fixture:
- #
- # <fixture-basename> OK <code> <data>
- # <fixture-basename> ERR <tp3-error-no> <relative-pos>
- #
- # Both the verdict AND the numbers are asserted by run_compile_tests.sh, so a
- # regression in the *reported error position* fails the suite just like a
- # regression in the generated code. That matters: error positions were once
- # silently wrong (a multi-character string literal swallowed the rest of the
- # source, so every later error pointed at end-of-file), and nothing caught it
- # because the old harness only printed the position for a human to squint at.
- #
- # Re-baseline deliberately, never to make a red test go green: if a fixture's
- # expectation has to change because the compiler legitimately improved, change
- # it in the same commit as the fix and say why in the message.
- #
- # ERR 102 = ENoLib, the original's "not implemented" path. The remaining ERR
- # rows are unimplemented features, not parser bugs:
- # t14 'array [..] of <type>' at its point of use
- # t25 a string literal used where a 16-bit word is wanted
- # uierror deliberate syntax error, pinned by the editor UI test
- #
- # t02 t03 t05 t17 used to be ERR 102 as well: a multi-character literal was
- # rejected because writeln had no string support. They compile now, via the
- # inline-string path (CALL wrtinl, then <length><chars> in the code stream -
- # TPSRC8 pwrinlin / TPSRC4 xwrtinl), so their rows changed from ERR to OK and
- # their code sizes went up by the literal's own bytes.
- #
- # RE-BASELINED when the runtime was wired into the code buffer. Every OK row
- # changed by exactly +3 code and -256 data, and both numbers are correct:
- #
- # +3 code the prologue now emits MOV AX,<header offset> before
- # CALL TU_InitMem, because InitMem takes the header offset in a
- # register (B8 lo hi) rather than on the stack. Previously the
- # prologue called offset 8, which is the hdrMax word - it only
- # "worked" because the runtime was not in the image at all.
- #
- # -256 data DataBytes() used to return dc, the ABSOLUTE end of the data
- # area, not a size. dc started at 100H, so every program reported
- # 256 more than it allocated - 260 for a program whose only data is
- # the two @@T1/@@T2 scratch words. The field is documented as
- # "emitted data size in bytes", so 4 is the true size and 260 was
- # the bug. It is a real correction, not a fit-to-the-test change:
- # the 6-byte rows are the fixtures that declare one global.
- t01_minimal OK 29 4
- t02_writeln OK 38 4
- t03_inline_comment OK 38 4
- t04_var OK 48 6
- t05_own_line_comment OK 38 4
- t06_two_args OK 52 4
- t07_big OK 102 6
- t08_const OK 35 6
- t09_if OK 67 6
- t10_while OK 75 6
- t11_for OK 69 6
- t12_repeat OK 72 6
- t13_proc OK 53 6
- t14_types ERR 102 83
- t15_label OK 38 6
- t16_str1 OK 42 4
- t17_two_str OK 45 4
- t18_writeln_bare OK 32 4
- t19_int1 OK 42 4
- t20_str3 OK 62 4
- t21_mixed OK 62 4
- t22_case OK 96 6
- t23_str_empty OK 36 4
- t24_str_quote OK 41 4
- t25_str_as_value ERR 102 48
- t26_str_mixed_args OK 58 4
- uierror ERR 41 331
|
