## Assignment 2: Static Checking (Part A)

In this assignment, you will implement a compiler phase that checks whether a Joos 1W program satisfies certain basic validity requirements. It is recommended that your design follow these four stages: abstract syntax tree building, environment building, type name resolution, and hierarchy checking.

### Abstract Syntax Tree Building

A parse tree built using an unambiguous grammar typically contains many redundant nodes. By recursively traversing the parse tree, it is possible to build an abstract syntax tree with an analogous structure but fewer nodes. An abstract syntax tree simplifies later phases of the compiler by reducing the number of nodes and the number of different kinds of nodes that each phase needs to handle. When a compiler is implemented using a statically typed language, distinct types are typically defined for each possible kind of tree nodes, so that later compiler phases can use the type to document the tree nodes that they handle.

### Environment Building

The environment building stage creates environments (containing classes, interfaces, fields, methods, local variables, and formal parameters) for each scope. Given a name of one of these entities, the environment should be able to locate the correct declaration of the entity.

After constructing all of the environments, the following requirements of the Joos 1W language must be checked:

• No two fields declared in the same class may have the same name.
• No two local variables with overlapping scope have the same name.
• No two classes or interfaces have the same canonical name.

The type linking stage connects each use of a named type (class or interface) to the declaration of the type. At this stage, only names that can be syntactically (according to JLS 6.5.1) determined to be names of types need to be linked. Some names are syntactically ambiguous, in the sense that type checking must be done before it can be determined whether they are names of types or of other entities (see JLS 6.5). These ambiguous names will be linked in a later assignment.

When linking type names, the following requirements of the Joos 1W language must be checked:

• No single-type-import declaration clashes with the class or interface declared in the same file.
• No two single-type-import declarations clash with each other.
• All type names must resolve to some class or interface declared in some file listed on the Joos command line.
• All simple type names must resolve to a unique class or interface.
• When a fully qualified name resolves to a type, no strict prefix of the fully qualified name can resolve to a type in the same environment.
• No package names—including their prefixes—of declared packages, single-type-import declarations or import-on-demand declarations that are used may resolve to types, except for types in the default, unnamed package.
• Every import-on-demand declaration must refer to a package declared in some file listed on the Joos command line. That is, the import-on-demand declaration must refer to a package whose name appears as the package declaration in some source file, or whose name is a prefix of the name appearing in some package declaration.

### Hierarchy Checking

The fourth stage computes the inheritance relationships for classes, interfaces, methods, and fields, and checks that they conform to the various rules given in Chapters 8 and 9 of the Java Language Specification. Specifically, this stage should check that:

• A class must not extend an interface. (JLS 8.1.3)
• A class must not implement a class. (JLS 8.1.4)
• An interface must not be repeated in an implements clause or in an extends clause of an interface. (JLS 8.1.4)
• A class must not extend a final class. (JLS 8.1.1.2, 8.1.3)
• An interface must not extend a class. (JLS 9.1.2)
• The hierarchy must be acyclic. (JLS 8.1.3, 9.1.2)
• A class or interface must not declare two methods with the same signature (name and parameter types). (JLS 8.4, 9.4)
• A class must not declare two constructors with the same parameter types (JLS 8.8.2)
• A class or interface must not contain (declare or inherit) two methods with the same signature but different return types (JLS 8.1.1.1, 8.4, 8.4.2, 8.4.6.3, 8.4.6.4, 9.2, 9.4.1)
• A class that contains (declares or inherits) any abstract methods must be abstract. (JLS 8.1.1.1)
• A nonstatic method must not replace a static method (JLS 8.4.6.1)
• A method must not replace a method with a different return type. (JLS 8.1.1.1, 8.4, 8.4.2, 8.4.6.3, 8.4.6.4, 9.2, 9.4.1)
• A protected method must not replace a public method. (JLS 8.4.6.3)
• A method must not replace a final method. (JLS 8.4.3.3)

### Hint/Warning

A common error in this assignment is that the compiler works correctly only when the source files are listed on the command line in a particular order, for example with all superclasses before their subclasses. When designing your compiler, be sure to consider that the source files could be listed in an arbitrary order. When testing your compiler, make sure that it still works correctly when the source files are reordered.

### Report Submission

You are not asked to submit a report for this assignment. However, Assignment 4 will require a report covering Assignments 2, 3, and 4, so it is recommended that you start writing such a document. Your report will follow the guidelines.

### Code Submission

As in Assignment 1, you must hand in to Marmoset a .zip archive containing your source code. It should include everything required to build and run your project. In particular, in addition to your source code, it should contain a file named Makefile. Marmoset will run make on this Makefile to build your compiler. The Makefile must generate an executable (binary or shell script) called joosc.

Unlike in Assignment 1, joosc in this and future assignments must be able to accept multiple filenames as arguments. All of the files listed on the joosc command line—and only those files—are considered part of the program being compiled.

Unlike javac, your joosc compiler should not look for classes in .class files on the CLASSPATH. Instead, it should read only those Joos 1W source files listed on the command line. Thus, all classes, including classes such as java.lang.Object, must be available in source form and must be specified on the joosc command line. Unlike javac, Joos does not care what directory a source file is in (i.e., it does not require the directory structure of the source code to match the package structure). However, the class declared in a file must still have the same name as the filename. For example, Java would require that the class java.lang.Object be declared in the file Object.java in the directory java/lang, whereas Joos only requires the file to be named Object.java but otherwise allows it to be in any directory.

For the purposes of this course, a minimalist version of the Java standard library is provided. This library can be found in the linux.student.cs environment in the directory /u/cs444/pub/stdlib/2.0. Marmoset will include all files in this library on the joosc command line for every test, in addition to other source file(s) specific to that test. The following versioning scheme is used to make it possible to correct errors and/or to extend the library for future assignments (although we aim to minimize the number of changes that will be required). The 2 in the directory name refers to Assignment 2, and the 0 is the first version of the library. Any corrections to the Assignment 2 version of the library will appear in the directories 2.1, 2.2, etc., and the version of the library for Assignment 3 will appear in the directory 3.0.

As in Assignment 1, joosc should process the Joos 1W files given on the command line, produce appropriate diagnostic messages on standard error, and exit with one of the following Unix return codes:

• 0: the input file is valid Joos 1W
• 42: the input file is not valid Joos 1W
• any other value: your compiler crashed

The archive should include all your test cases and test code that you used to test your program. Be sure to mention where these files are in your report. Do not include Marmoset public tests.

The archive should include a file named a2.log showing the commit history of your Git repository.

The archive should not include any extraneous non-source files. It should not include any files that ought to be automatically generated by building or running your compiler.

Your build process should not transmit data from/to the internet in any way.

We reserve the right to deduct points if your submission does not meet the requirements above.

The Marmoset tests for this assignment take several minutes to run. Do not submit more than one submission at a time to Marmoset. If Marmoset reports that your previous submission has not been tested yet, do not submit another one. Denial-of-service attacks on Marmoset will result in disciplinary action.