Project 6 Perform full type checking for Tiger language.

Description:
This is a team project that build on the previous project. In this project, you are required to perform
full type checking for Tiger language.
.
What to do in this project?
Your major task in this project is to provide implementation for most member functions of class
TypeChecking to detect all static semantic errors. The member functions to be implemented are
specified by the comments. No other files need to be modified.
When you implement each member function, please refer to the slides at
http://www.cs.mtsu.edu/~zdong/4160/public/slides/TypeChecking.pdf
Classes in this project
The new class introduced in this project is types::Type and its descendants, which are used to define
types associated to variables and type definitions in Tiger language
 Class Type: the abstract base class. It defines two virtual member functions
o types::Type* actual(): It returns the real data type. See NAME type.
o Bool coerceTo(const Type *t): it returns true if t can be converted to current type,
otherwise returns false. This function is needed in order to check type compatibility.
 Class ARRAY: represent array data type.
 Class RECORD: represent record data type.
 Class FUNCTION: represent function signature.
 Class INT: represent integer data type
 Class STRING: represent string data type
 Class NIL: represent NIL constant
 Class VOID: represent void type
 Class NAME: represent the alias name of an existing data type. For example, the statement
below defines a new data type in Tiger language:
type money = int
Then, a NAME object can be created to represent the money type.
NAME *n = new NAME(“money);
n-bind( new types::INT() );
In this case, the statement n-actual() will return a pointer to types::INT object, which is the
real data type of money.
Tips for the project
 When should I use the member function Type::actual()?
ANSWER: Everytime when you return a variable (say t) of (type::Type *) in TypeChecking::visit
function, you should return t-actual() instead of t. For example, see TypeChecking::visit(const
VarExp *) in TypeChecking.cpp file provided by the instructor ..
 Assume we have the declaration: type::Type *t; after some assignment statement to variable t;
how can we check if it actually points to an object of some type, say FUNCTION?
ANSWER: Use dynamic_cast. For example, if the Boolean expression below is true, it means t
points to a FUNCTION object.
dynamic_cast<const types::FUNCTION *(t) != NULL
 Assume we have declarations: type::Type *t1, *t2; after some assignment statement to both
variables, how to check if these two types are compatible?ANSWER: use coerceTo function. If t1.coerceTo(t2) is true, it means type represented by t2 can
be converted to the type represented by t1. If t2.coerceTo(t1) is true, it means type represented by
t1 can be converted to the type represented by t2.
 Each TypeChecking::visit function returns a pointer to types::Type. So if an expression contains a
semantic error, what should be returned? For example: expression 1 + “a string” is semantically
wrong, and if it is passed to TypeChecking::visit(const OpExp * e), what is supposed to return?
ANSWER: If an expression contains a semantic error (undefined variable used, type doesn’t
match), always treat the type of the expression as INT.
Test Report:
In this project, implementation of the project and test case design can be performed simultaneously.
Don’t wait too long to design test cases. In this project, please provide a tiger program called: test.tig
to cover all of the following scenarios:
 Type checking on OpExp like: exp1 operator exp2
o If operator is +, -, *, or /
 exp1 is not an integer (test case 1)
 exp2 is not an integer (test case 2)
o If operator is =, or <
 Types of exp1 and exp2 doesn’t match (test case 3)
 Exp1 is NIL but exp2 is not an array or record (test case 4)
 Both exp1 and exp2 are NIL (test case 5)
o If operator is <, <=, , or =
 One operand is neither INT nor STRING (test case 6)
 One operand is INT, and the other one is STRING (test case 7)
 Type checking on CallExp like: fname(exp1, exp2, …, expn)
o fname is not defined (test case 8)
o fname is defined as a variable (test case 9)
o too many arguments (test case 10)
o less arguments than required (test case 11)
o one expression has wrong data type (test case 12)
 Type checking on AssignExp like: lvalue := exp
o Types of lvalue and exp don’t match (test case 13)
 Type checking on IfExp like: if exp1 then exp2 else exp3
o exp1 is not an integer (test case 14)
o if there is no else-clause, exp2 is not VOID type (test case 15)
o if there is else-clause, types of exp2 and exp3 don’t match (test case 16)
 Type checking on WhileExp
o The body of the loop is not VOID type (test case 17)
 Type checking on ForExp like: for varname := exp1 to exp2 do exp3
o exp1 is not an integer expression (test case 18)
o exp2 is not an integer expression (test case 19)
o exp3 is not VOID type (test case 20)
 Type checking on FunctionDec like: function fname (p1:Type1, …, pn:Typen) : ReturnType =
exp
o fname already exists (test case 21)
o The type of an argument is not defined (test case 22)
o Two parameters have the same name (test case 23)
o The type of exp doesn’t match ReturnType (test case 24)
 Type checking on VarDec like: var vname : TypeName := exp (test case 25)
o Type of exp doesn’t match TypeName (test case 26)
o If TypeName is omitted, and exp is NIL. (test case 27)Please put the test report, and test.tig in the project6/testing folder of team repository.Important Dates and Deadlines:
Monday Tuesday Wednesday Thursday Friday Saturday Sunday
20
Project
assigned
21 22 23
1st time log
report due
24 25 26
27 28
2nd time log
report due
29 30 1 (Dec.)
Test.tig and
alpha
version due
2 3
4
Test report
due
Project Due
5 6 7 8 9
Notes:
 All reports/files are due at 4:00am on the due day.
 Each team is required to submit 2 time log reports.
Instructor provided files in the class repository
The following files are provided by the instructor:
 TypeCheckingProject folder. This contains a sample Visual Studio 2010 project.
 Description6.pdf: this file
 Rubric6.doc: the rubric used to grade this assignment.
 example.txt. sample output
 Testreport.doc: format of testing report for this projectHow to submit
1. Once you have finished, submit the project in the following way:
 Group leader needs to make sure files and reports are placed in the right folder, and have
been pushed to the master repository in ranger.
 Put test case, test report under Testing folder
 Put alpha version of TypeChecking.cpp and SymbolTable.cpp under
AlphaVersion folder
 Put timelog reports under Timelog folder
 Leave the final version under folder SymbolTableProject folder
 Any commit of the project after the deadline is considered as cheating. If this
happens, the latest version before the deadline will be graded, and you may receive
up to 50 points deduction.
 Each team is required to submit hard copies of the following files. Please put copies
of these files in a folder/envelope of size 9 x 12. You can buy folders from lab
assistant at KOM 351.
 testing report
 test.tig
 2 timelog reports
 TypeChecking.cpp (alpha version)
 TypeChecking.cpp (final version)
Write down team number, and names of all team member on the cover. Give the
folder/envelope to the instructor at the beginning of the class on the due day.
You can check your overall grade by pull rubric3.doc from the master repository after the notice from
the instructor.