Due: Tuesday, Feb. 2 by 11 pm. Turn in your project using the assignment drop box (links on the project page).
For this assignment, construct a parser (recognizer) for MiniJava. You should use the CUP parser generator tool to interface with your JFlex scanner. Be sure that your parser and scanner together can successfully parse legal MiniJava programs.
Don't include any semantic actions in the parser until you have the parser itself working. The semantic actions to build the AST make up the next part of the project. Feel free to experiment with language extensions (additional Java constructs not included in MiniJava) or syntactic error recovery if you wish, but be sure to get the basic parser working first.
You may need to massage the MiniJava grammar to make it LALR(1) so that CUP can use it to produce a parser. Please keep track of the changes you make and turn in a description of them with this part of the project (see below).
Take advantage of precedence and associativity declarations in the parser specification to keep the overall size of the parser grammar small. (In particular, a production exp ::= exp op exp along with precedence and associativity declarations for various operators will shorten the specification considerably compared to a grammar that encodes that information in separate productions.) CUP's input syntax is basically the same that used by YACC, described in many compiler books. It should be easy enough to pick up the syntactic details from the CUP documentation and example code.
Your grammar should not contain any reduce-reduce conflicts, and should have as few shift-reduce conflicts as possible. You should describe the remaining shift-reduce conflicts in your writeup.
You should test your parser by processing several MiniJava programs, both correct ones and ones with syntax errors. Your compiler need only indicate a successful parse or a syntax error, but, of course, better error reporting is a great extension to the project.
The main things we'll be looking at in this phase of the project are the following:
As before, your code should run on attu when built with ant. You should do an "ant clean", then bundle up your compiler directory in a tar file and turn that in. That will ensure that we have all the pieces of your compiler if we need to check something.
You and your partner should turn in only a single copy of the project using one of your UW netids, preferably the same one you used for the scanner, although this is not required. Your readme file should include your names and uw netids so we can correctly identify everyone involved in the group and get feedback to you. Multiple turnins are fine - we'll grade the last one you give us. In particular, if you plan on adding error handling or other extra features, turn in a copy of the working, basic assignment first before you add these, then turn in the enhanced parser later once you have it working.