The essential task performed here is to associate the declaration of a name to the relevant uses of that declared name.

• JavaDoc for this project will be installed with the code you import. The documentation can also be found here, including the code you use in the hw3 and hw4 packages.
• You need to install the following jar files in the same place you installed such files in previous labs. Make sure they are really stored as jar files and not zip files.
  • parser.jar is my implementation of the Lab 3 parser (see explanation of its use, below)
  • classsolutions.jar is my implementation of the parts of ths lab, so you can test out your parts independently.
  • If you need to install them again, here are the jars from Lab 3:
    • makesymstring.jar needed to build your parser
    • java-cup-11a.jar is needed to build your parser and to run the project.
• Download this zip file for this lab into a temporary spot, and import it as an existing eclipse project (or, use it standalone under Linux).
  Notes:
  • Change YourToolPath in both build.xml files to reflect where you've stored the jar files:
    • build.xml at the top project-level
    • build.xml in the parser package
  • Cause the build to happen in the same JRE as eclipse.
  • Cause the workspace to be refreshed after a build.
  • Add the jar files (parser, java-cup-11a, and classsolutions) to the Build Path of this project
• In this lab, you will need a working implementation of Lab 3 , in the form of a parser that creates an abstract syntax tree (AST). The AST will need a handful of specialized nodes so that the symbol table visitor can intercept and handle symbol declarations and uses.

  There are two ways for you to do this, and either way is acceptable:

  • You can use my implementation via the parser.jar library. The software you install will by default use my parser implementation.
  • You can use your own implementation:
    1. Copy your jmm.cup from Lab 3 into the parser package of the workspace for Lab 4.
    2. At the top of jmm.cup, insert

          package parser;
       

       so that the generated parser is in the right package.
    3. In the rule for the goal symbol CompilationUnit, be sure to set RESULT to the root node of the parse tree in the semantic action.
    4. In the build.xml file, be sure that the class path element for the current directory "." is ahead of the parser.jar path element, so your implementation is found ahead of mine.
• To run the project on the test files, run build.xml as an ant task, picking the testMySolution target.
• Take note of the following classes and their usage in this lab:

  SymtabVisitor.java	This is the only file you will submit. It contains the visitor as a public class and an implementation of a symbol table as a non-public class. Instructions on its use are found in the code and its documentation.
  ClassSymtabVisitor.class	This is my implementation of the visitor, found in classsolutions.jar. Your installed code will use it until you make the appropriate change in SymtabVisitor. You'll have to change over to your implementation because that's what you're turning in for ths lab.
  ClassBuildSymtab.class	This is my implementation of the symbol table itself, found in classsolutions.jar For this lab, you can continue using mine unless you want to use your own, or the one you developed in Studio, in which case you should make the appropriate change in SymtabVisitor.

• As installed, you are running my solution. Take a look at the AST dump to see the structure of my AST (or use your own from Lab 3). The indentation of the symbol-table pass shows the nest level.
• For hints on how to do the visitor, consult the documentation for my symbol-table visitor . In particular, note the visit methods present in that solution:
  • ClassDeclaring: Check that the name isn't already in the symbol table.

  • MethodDeclaring: Check that the name isn't already in the symbol table. You should then pass the visitor on to the parameters and to the method's body. What you do with nest levels in and around those calls will affect how scoping works in your compiler. Document your approach using comments in the code you submit.

  • FieldDeclaring: Check for duplicate declaration, but treat the name as though "this." were prepended to it.

  • LocalDeclaring: If the symbol is already declared at the current nest level, complain as directed below. Otherwise, get this symbols type information, and enter the symbol and its type information into the symbol table. Look up the symbol in the symbol table, and use the setSymInfo method to set the symbol information for this declaration in the AST (so it looks nice when it prints).

  • LocalReferencing: Make sure there is a valid entry for the symbol in the symbol table at this point. Call setSymInfo on this node to establish the map between the reference and its type declaration.

  • BlockIsh: manipulate scopes properly and pass the visitor on.
• The information set and retrieved from the symbol table must be an implementation of the SymInfo interface. So you must develop a local class within SymtabVisitor (because that's the only file you turn in) that implements that interface, and you will have to instantiate it appropriately for a symbol before you insert the symbol into the symbol table.

  Don't worry aobut the getRegister/setRegister methods -- they are used later.

• If you detect an undeclared reference, your output must contain the phrase

  Error: Undefined Reference

  and indicate the offending node. The easiest way to do this is to use the out method: see the documentation
• Likewise,if there is a symbol that is multiply declared, then you must emit a message

  Error: Duplicate declaration

• To turn in your work send SymtabVisitor.java as an email attachment to legrand@cs .