Average time to complete: 15-20 hours
Perform semantic analysis on MiniDream programs. Your program must continue to detect all lexical and syntactic errors, and must now detect certain semantic errors in the program (assuming the program is syntactically correct). Your semantic checker must report all semantic errors in the program. See below for a list of errors you must report.
Use the same format for reporting semantic errors as you have used for lexical and syntactic error messages (filename:line,col:error message). Submissions omitting location information will receive an automatic F.
At the end, your program should report the total number of semantic errors found.
Your program will be invoked from the command line as follows:
build/install/dream/bin/dream [-ds] [-dp] <filename>
where <filename> is the name of a MiniDream source file.
Test files are provided in the class files in /tests/phase3.
See this document for tips on how to tackle this phase.
Here is a list of the semantic errors you must report, along with a sample error message:
undeclared variables
Sample message: “Use of undeclared variable x”
variables/methods of the same name declared at the same scope level (redeclared variables/methods)
supplying the wrong number of actual parameters to a method
Sample message: “Expected 0 parameters in call to readint( ); received 1”
failure to define exactly one class in a source file
type errors (see below)
Notes on Unsupported Features:
As stated in the MiniDream semantics, MiniDream programs are not allowed to contain user-defined methods other than the start method. However, in this phase, you are required to perform complete semantic checking on programs containing user-defined methods with parameters and local variables, to prepare you for Phase 5, when user-defined methods must be handled.
MiniDream programs are not allowed to use the string data type or string literals. However, your semantic checker should perform normal type checking on such programs. This, too, will streamline your transition to Phase 5.
There are many ways to get type errors. Here is the list of errors you must detect.
Operands of incorrect type for operator (& requires strings; >/>= require int or string (both operands must be same type); = requires int, string, or boolean (both operands must be same type); +-*/ require int; and/or/not require boolean)
Sample: “Incorrect type for &: requires strings, given int and string”
Assignment statement requires LHS to be the same type as the RHS
Sample: “Type mismatch in assignment statement: expected int on RHS, got string”
Expressions in if and loop while tests must be boolean
Method calls require formal parameters to be the same type as the corresponding actuals.
Note that, for a given expression, try to report only the first type error that you encounter involving that expression. For a given expression, a type error near the leaves should not result in a cascade of error messages.
Create README.md in the root of the dream folder with the number of hours you spent on this phase, and list any known bugs. Also, include an academic integrity statement indicating what help you received, if any.
Ensure that your code is pushed to the submission system.