The Test Manual said an xfail test records the assembler's refusal message and so catches both an error that stops being detected and a message that changes without anybody meaning it to. It did not. run.sh checked only that the assembler exited non zero, printed the first line for a person to read, and compared nothing; --bless recorded nothing for these sixteen tests at all. So an xfail passed four different ways that look identical from outside: the intended error fired, an unrelated error fired, the message changed, or the assembler fell over on its way to the point. That is the documentation describing behaviour the code does not have, which is the exact failure Tests/docs.sh exists to prevent, in the manual that argues for knowing what your evidence is worth. The diagnostic is now stripped of colour, given the same [exit N] line every other recorded result carries, and compared through check() like anything else. Sixteen results recorded; every existing one is byte for byte unchanged. Verified the way the manual asks: one diagnostic was broken on purpose, its test failed with the changed line in the diff, and its neighbour passed. Found by ChatGPT reviewing the manual. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW
9 lines
395 B
Plaintext
9 lines
395 B
Plaintext
Error: A string cannot go in the Program Segment.
|
|
Strings live in Data Memory, which is the only memory an instruction
|
|
can read. A string in Program Memory could not be reached even by the
|
|
program holding it, except through the memory controller.
|
|
File: testPrograms/diagnostics/stringInProgram.asm at line 19.
|
|
The string: "this is not where this goes"
|
|
Move it below a #Data line.
|
|
[exit 1]
|