Type checking
Lecture 11

Declarations

f() {
}

main() {
  int y;
  y = 2;  // okay, because y and 2 are both int
  y = f;  // not okay, because y is an int and f is a function
}

Scoping

f() {
  bool y;
  y = true;  // okay, because y is a bool in f's scope
}

main() {
  int y;
  y = true;  // not okay, because this is a different "y"
}

The symbol table

Example

What is a type?

Type rules for operations

What about operations between types?

Symbol table

Scoping

Collecting declarations

Getting types of variable usages

Leaf nodes

Inner nodes

Example

f() {
  return 10;
}

main() {
  int x;
  input x;
  return x * 2 + f();
}

Functions act like implication

Tips

• Look at the grammar
  

  The grammar is the guide the what symbols are available in each visitor from the right-hand side.

• Be sure to recursively visit child non-terminals
  

  In binary operations, for instance, be sure to visit both the left and right operands at some point, i.e., visit(ctx.expr(0)) and visit(ctx.expr(1)) (in ANTLR, if there are multiple expr non-terminals, pass the 0-based index to get the corresponding one). What is the return value and what does it mean?

  In statements, be sure to visit any expression used and the statements. For instance, while loops need to visit both the condition expression visit(ctx.expr()) and the body visit(ctx.stmt()). The if-then-else production has a condition visit(ctx.expr()) and two statements, visit(ctx.stmt(0)) and visit(ctx.stmt(1)) for the if- and else-branches respectively.

• Expression visitors return the type
  

  The type-checker behaves like an interpreter (recall the Calc example). But the "value" produced is a type name, rather than an integer. The visitor is setup to just use a string to hold the type name. SimpleC only has two possible types that expressions can produce, "int" and "bool". Like an interpreter, evaluating expressions means first evaluating any operands in the expression. Statements have no return value in our visitor, since the state is instead held in the symbol tables functions and variables. Statements only need return null, since the visitor has type Void instead of void.

• Reporting type errors
  

  Use the provided type_error method to report an error. This takes ctx and automatically prints the file, line, and column of the error, while also exiting with error code 2 (which will be used to enabled automated grading). While it is not checked or required, you may also report an error message to stderr, e.g.,

  if (! "int".equals(temp)) {
    System.err.println("return type should be int");
    typeError(ctx);
  }
  

• Use .equals() not == for string equality in Java
  

  Checking whether temp is the same string as "int" is done with "int".equals(temp). The double-equals == checks reference equality, which may not be equal for string objects even when their list of characters are the same.

• Work bottom-up and write tests as you implement
  

  Instead of trying to implement everything in one go, break the type-checker down into pieces, e.g., one visitor function at-a-time. Working bottom-up is likely easiest, since the inner nodes depend on their child nodes. Add calls to visit or remove/comment out other visitors to let the default visitor ensure that the entire tree is traversed (otherwise you may not hit the visitor you are working on). Try this suggested workflow:

  1. Pick a visitor to work with, starting from the bottom of the grammar.
  2. Look at the type-specification and grammar to start planning the implementation
  3. Create a test case that should exercise the type specification
  4. Use print statments to ensure that the visitor is actually reached by the test case
  5. Collect the required ANTLR calls and symbol table operations needed to implement the specification. What children are needed, e.g., ctx.expr(), ctx.ID().getText()? What, if any, symbol table operations are needed, i.e., get and put? How will the type comparison be done, e.g., string equality check, visiting a child, looking up in a type, etc.? Have these opeerations hand so you don't have to think about them while implementing the visitor.
  6. Carefully implement the logic of the specification. If you are unsure, use examples to help reason through the behavior. Ask on the class discussion if the specification appears ambiguous. Ensure the implementation compiles.
  7. Double-check that all possible cases for the visitor are handled by your implementation.
  8. Write extra test cases the ensure that at a minimum each code path is exercised by your tests.
  9. Test your implementation, fixing any minor bugs or logic issues.
  10. Once you have a piece of the implementation working, commit with the test cases and a meaningful commit message.
  11. Admire your work and take pride in writing solid code!
  12. Repeat
• An incomplete type-checker implementation may not crash
  

  The lack of a crash is not enough information to say that a program is written correctly. Use print statements (or debugging) to confirm that the piece you have implemented is producing the expected values. Use counter-examples, such as known type-unsafe programs, to make sure the type-checker isn't letting through unsafe programs unexpectedly.

Submission

Grading