Massachusetts Institute of Technology Department of Electrical Engineering and Computer Science 6.035, Spring 2010 Handout — Semantic Analysis Project Tuesday, Feb 16 DUE: Monday, Mar 1 Extend your compiler to find, report, and recover from semantic err or s in Decaf programs. Most semantic errors can be checked by testing the rules enumerated in the section “Semantic Rules” of Decaf Spec. These rules are repeated in this handout as well. However, you should read Decaf Spec in its entirety to make sure t hat your compiler catches all semantic errors implied by the language definition. We have attempted to provide a precise statement of the se mantic rules. If you fee l some semantic rule i n the language definition may have multiple interpretations, you should work with the interpretation that sounds most reasonable to you and clearly list your assumptions i n your project documentationThis part of the proje c t i nc l ude s the fol l owing task s: 1. Create a high-level intermediate representation (IR) tree. You can do thi s either by instructing ANTLR to create one for you, adding actions to your grammar to build a tree, or walking a generic ANTLR tree and building a tr e e on the way. The problem of designing an IR will be discussed in the lectures; some hints are given in the final section of this handout. When running in debug mode, your driver should pretty-print the constructed IR tree in some easily-readable form suitable for debugging. 2. Build symbol tables for t he classes. (A symbol table is an e nvironment, i.e. a mapping from identifiers to semantic objects such as variable declarat i ons. Environments are structured hierarchically, in parallel with source-level constructs, such as class-bodies, method-bodies, loop-bodies, etc . ) 3. Perform all semantic checks by traversing the IR and accessing the symbol tables. Note: the run-time checks are not required for this assignment. What to Hand In Follow the directions given in pr oject overview handout when writing up your project. Your design documentation should include a description of how your IR and symbol table structures are organized, as well as a discussion of your design for performing the semantic checks. Each group will be assigned an athena group and shared space in the course locker. Each group must place their completed submission at: /mit/6.035/group/GROUP/submit/GROUP-semantics.tar.gz Groups may use: /mit/6.035/group/GROUP/ as a place to collaborate and share code. It is recommended that you use revision control and place your repositories in this shared space. Submitted tarballs should have the following structure: *Athena is MIT's UNIX-based computing environment. OCW does not provide access to it. .GROUPNAME-semantics.tar.gz | ‘-- GROUPNAME-semantics | |-- AUTHORS (list of students in your group, one per line) | |-- code | | | ... (full source code, can build by running ‘ant‘) | |-- doc | | | ... (write-up, described in project overview handout) | ‘-- dist | ‘-- Compiler.jar (compiled output, for automated testing) You should be able to run your compiler from the command line with: java -jar dist/Compiler.jar -target inter <filename> The result i ng output to the terminal should be a report of all errors encountered while compiling the file. Your compiler should give reasonable and specific error messages (with li ne and column numbers and identifier names) for all errors detected. It should avoid reporting multiple error messages for the same error. For example, if y has not been declared in the assignment statement “x=y+1;”, the compiler should report only one error message for y, rather than one error message for y, another error message for the +, and yet another error message for the assignment. After you implement the static semantic checker, your compiler should be able to detect and report all static (i.e., compile-time) errors in any input Decaf program, including lexical and syntax errors detected by previous phases of the compiler. In addition, your compiler should not report any messages for valid Decaf programs. However, we do not e x pect you to avoid reporting spurious error messages that ge t trigger e d by error recovery. It is possible that your compiler might mistak-enly report spurious semantic errors in some cases depending on the effectiveness of your parser’s syntactic error recovery. As mentioned, your compiler should have a debug mode in which the IR and symbol table data structures constructed by your compiler are pri nted in some form. This can be run from the command line by java -jar dist/Compiler.jar -target inter -debug <filename> Test Cases The test cases provided for this project are in: /mit/6.035/provided/semantics/ Read t he comments in the test cases to see what we expect your compiler to do. Points will be awarded based on how well your compiler p e r for ms on these and hi d de n tests cases. Complete documentation is also required for full credit. 2Grading Script As with the previous project, we are providing you with the grading script we will use to test your code ( e x c e pt for the writ e -up) . This script only shows you results for the public test cases. The script can be found on athe na in the c our se locker: /mit/6.035/provided/gradingscripts/p2grader.py The script takes your tarball as the only arg: /mit/6.035/provided/gradingscripts/p2grader.py GROUPNAME-parser.tar.gz Or it works on the extracted directory: /mit/6.035/provided/gradingscripts/p2grader.py GROUPNAME-parser/ Please test your submission against this script. It may help you debug your code and it will help make the grading process go more smoothly. Semantic Rules These rule s place additional constraints on the set of valid Decaf programs besides the c onst r ai nts implied by the grammar. A program that is