Assignment 3: Static Checking (Part B)

In this assignment, you will implement disambiguation of names and type checking.

Disambiguation of Names

The disambiguation stage determines the meaning of each remaining use of a name and links the use to the declaration of the entity (field, method, local variable, formal parameter, or type) that the name refers to. Disambiguation of syntactically ambiguous names is specified in Section 6.5.2 of the Java Language Specification and was discussed in class.

Note that Joos 1W supports a simplified version of method overloading compared to the full Java overloading rules detailed in Section 15.12.2 of the Java Language Specification. Although Joos 1W does allow method overloading (i.e., multiple methods with the same name, but different parameter types), the declared types of the parameters must exactly match the static types of the argument expressions in order for the method to be called. For example, a call such as bar('x') will not invoke a method with signature bar(int), as it would in Java, but the call bar((int)'x') would.

If a prefix of a name refers to a variable or field, then the remaining part of the name refers to non-static field(s) or a method of the object referred to by that variable or field. At this stage, non-static fields and methods are not resolved; it is deferred until the type checking stage, when the static type of the base variable or field is known.

During and/or after disambiguation of names, the following restrictions of the Joos 1W language must be checked:

• Check that all names, except for non-static field and method accesses, can be disambiguated. It is an error if a name cannot be resolved to any entity that is in scope at the point where the name is used.
• Check the rules specified in Section 8.3.2.3 of the Java Language Specification regarding forward references. The initializer of a non-static field must not use (i.e., read) by simple name (i.e., without an explicit this) itself or a non-static field declared later in the same class.

Type Checking

The type checking stage determines the types of all expressions and subexpressions, checks that they conform to the Joos 1W typing rules, and links all remaining names (i.e., non-static field accesses and method calls) to the declarations that they refer to.

It is possible for a class to contain multiple methods with the same signature, all abstract, and all inherited from one of its superclasses. In this case, the method call may be linked to any one of these methods, since they are guaranteed to have the same return type.

During and/or after type checking, the following restrictions of the Joos 1W language must be checked:

• Check that the types of all expressions and subexpressions conform to the Joos 1W typing rules and that all statements are type-correct. The Joos 1W typing rules are the same as the Java typing rules with the following exceptions:

  • Assignability is the same as in Java (see Section 5.2 of the Java Language Specification), except that narrowing conversions are never allowed.
  • The rules for casts to reference types are simplified relative to the rules specified in Section 5.5 of the Java Language Specification. In a cast to a reference type T, the type of the subexpression S must be such that either S is assignable to T, T is assignable to S, or one of S or T is an interface and the other is either an interface or a non-final class. The rules for casts to primitive types are the same as in Java. When S and T are reference types, a subexpression of type S[] may be cast to type T[] if and only if a subexpression of type S may be cast to type T. Like in Java, the Joos 1W typing rules for instanceof expressions and equality comparisons (== and !=) are defined in terms of the rules for casts.

• Check that all non-static field and method uses can be resolved to fields and methods that exist.

• Check that fields/methods accessed as static are actually static, and that fields/methods accessed as non-static are actually non-static.

• Check that all accesses of protected fields, methods and constructors are in a subtype of the type declaring the entity being accessed, or in the same package as that type.

• Check that the name of a constructor is the same as the name of its enclosing class.

• A constructor in a class other than java.lang.Object implicitly calls the zero-argument constructor of its superclass. Check that this zero-argument constructor exists.

• Check that no objects of abstract classes are created.

• Check that no bitwise operations occur.

• Check that the implicit this variable is not accessed in a static method or in the initializer of a static field.

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 2, you must hand in to Marmoset a .zip archive containing your source code. The .zip file must contain a file called Makefile. Marmoset will run make on this Makefile to compile your compiler. The Makefile must generate an executable (binary or shell script) called joosc. The joosc executable must 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; it should read only the Joos 1W source files listed on the command line. This means that 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/3.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 3 in the directory name refers to Assignment 3, and the 0 is the first version of the library. Any corrections to the Assignment 3 version of the library will appear in the directories 3.1, 3.2, etc., and the version of the library for Assignment 4 will appear in the directory 4.0.

Version 3.0 of the standard library is identical to version 2.0.

As in previous assignments, 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 a3.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.