The point
Audit somebody else's compiler adversarially. The Topic 5 objective is literally audit the correctness of the AST and semantic actions of the parser — this is that, done to each other.
How to run it
- Everyone writes five adversarial programs — designed to break a compiler that was tested casually. Starting points:
- an
ifwith an empty body, or a bare block as its body ifinside a loop inside anif- a
breakinside a switch inside a loop - a switch whose controlling expression is a function call
- a case body containing a
return if (a) if (b) X else Ywith all four truth combinations- a switch with no
defaultand no matching case 2 && 1, and!5
- an
- Write the expected output for each, by hand, before running anything.
- Rotate. Run your five on both other compilers and record every disagreement.
- Diagnose by phase. For each failure, find the phase responsible. The AST dump is the fastest tool: if the tree is wrong, nothing downstream can be right, and the search is narrowed to two files.
- Fix one bug each, in your own compiler, before the session ends.
The one that catches almost everyone
A return inside a switch case. If the return does not jump to the function epilogue, control falls through into the next case body and the function returns whatever the last case says. It is invisible until somebody writes exactly that program — which is the point of an adversarial session.
Deliverable
Your five programs with expected outputs; a table of which compilers failed which tests; and a one-paragraph diagnosis of the bug you fixed, naming the phase and the line.