CS 444/644 - Compiler Construction (Winter 2026) - Assignment 3
For the third assignment, you will implement disambiguation of names and
type checking.
Disambiguation and Linking 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;
this 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 non-static field and method
accesses) can be disambiguated. It is an
error if a name cannot be linked 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.
Code Submission
Submit to Marmoset a .zip archive containing
everything required to build and run your project.
It should also include all your test cases and test code that you used to
test your compiler.
It must also include a file named git.log showing the commit history
of your Git repository.
In addition to the above, the .zip file should contain a
file named Makefile in the root directory. Marmoset will run make on this Makefile
to build your compiler. The Makefile must generate an executable
(binary or shell script) called joosc.
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
Your build process and execution of joosc should not send or receive data from/to the internet
in any way.
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.
Document Submission
You are not required to submit a design document for this assignment.
However, Assignment 4 will require a design document covering
your design decisions for Assignments 2, 3, and 4, so it is
recommended that you start writing such a document.
Refer to Assignment 4 for the formatting requirements and
suggested content of the document.