Project C: The MiniJava Typechecker

Due: Thursday, February 19, 2009 at 11:00 pm. Use the online dropbox to turn in your files.

Changed 2/16: Please submit an archive containing your entire compiler up to this point when you submit this and later parts of the project. It will help us do a better job of evaluating your code.

In this assignment you will extend the initial MiniJava typechecker with the extensions described in the course project description handout.

You should complete the front-end processing for the extended MiniJava language, checking any legality constraints not handled earlier in the scanning or parsing phases.  These include the following additions to the hierarchies in the Typechecker package:

You should implement typechecking for the new and/or modified AST node classes, including the following:

In all cases, as long as the MiniJava restrictions are satisfied, a MiniJava expression should have the same result type as the equivalent Java expression. 

You only need to get the compiler front-end to work. You do not need to implement any back-end lowering or code generation.

Do the following:

  1. Add and/or modify classes in the AST and Typechecker subdirectories to typecheck the extended language.
  2. Develop test cases that demonstrate that your extended typechecker works, both in cases that should now be legal and in cases that should be syntactically legal but semantically illegal. (Since the typechecker quits at the first error, you'll likely need several illegal test case files to test the different illegal cases.) You do not need to check for lexical or syntactic errors, just semantic errors. The SamplePrograms directory contains some files that should typecheck after you make your changes; some of the files should typecheck successfully with the initial version of the MiniJava compiler.

You can use the -typecheck -printSymbolTables options to the MiniJava compiler to just run the typechecking phase and print out the top-level symbol tables that it builds. See the test_typechecker target in the Makefilefor an example, and feel free to make your own target(s) to make running the tests you like easier and more mechanical.

Turn in the following:

  1. Your entire compiler source tree compete with the Makefile and any other files needed to build it. If possible, please do a make clean to save some space before you turn in the sources. Clearly identify any modifications to existing files using comments.
  2. Your test cases, with names of the form for test cases that should typecheck successfully and for test cases that should trigger typechecking errors.
  3. A transcript of running your typechecker and printing out the resulting symbol tables on each of your test cases.

Create a single archive containing these files and turn it in by the due date.