On the fifth day, you should specify test cases for the static analysis of !MiniJava programs.

---++ Initial Project

You should start the second milestone from a new initial project.
First, either close or delete your project for the first milestone.
Second, import the [[%ATTACHURL%/MiniJava-minimal2.zip][initial project]] using the _Import > General/Existing Projects into Workspace_ wizard.
Next, Build the project by selecting it and choosing _Project > Build Project_ from the menu.
The console will report success or failure.
Finally, study the constructors used in ASTs.
You can do this either by inspecting the AST of an example program or by inspecting the signature in =assignment1/MiniJava.str=.
---++ Test Cases

Like in the first milestone, you should specify test cases before you start with the implementation. 
You need three types of test cases:

	1. Tests for reference resolution. Define test cases for different kinds of references to declarations.
	1. Tests for error checking. Define test cases for checking errors which are related to names and types.
	1. Tests for transformations. Define test cases for the results of type projections.
	
---+++ Testing Reference Resolution

In test cases for reference resolution, you need to mark names at definition and use sites with inner square bracket blocks.
You can then relate the use site with the definition site in a =resolve ... to ...= clause, using numbers to refer to the inner blocks.
For example, the following two test cases require to resolve the type =Foo= to the name in the definition of class =Foo=:

<verbatim>
test forward class name resolution [[
  class Main {
	 public static void main(String[] args) {
		System.out.println(1);
	 }
  }

  class Foobar {
	 [[Foo]] x;
  }

  class [[Foo]] {}
]] resolve #1 to #2

test backward class name resolution [[
  class Main {
	 public static void main(String[] args) {
		System.out.println(1);
	 }
  }

  class [[Foo]] {}

  class Foobar {
	 [[Foo]] x;
  }
]] resolve #2 to #1
</verbatim>

<table style="border: 2px solid #D0D0D0; padding: 5px; width: 80%; background-color: #f0f9ff; margin-left:auto; margin-right:auto; border-spacing: 5px"><tr><td>
%T% _Tip:_ You can use setup headers and footers to avoid repeating parts in similar test cases.
</td></tr>
</table>

---+++ Testing Error Checking

In test cases for error checking, you need o specify the number of errors, warnings, or notes in a test case in =... errors=, =... warnings=, or =... notes=  clauses. 
You can use inner square bracket blocks to mark the positions where messages should be reported.
For example, the following test cases specify a correct !MiniJava program, a program with two errors which are reported on the name of a duplicate class =Foo=, and another program with a warning which is reported on the name of an unused class =Foobar=:

<verbatim>
test correct program [[
  class Main {
	 public static void main(String[] args) {
		System.out.println(1);
	 }
  }

  class Foo {}

  class Foobar {
	 Foo x;
  }
]] 0 errors

test error on duplicate class [[
  class Main {
	 public static void main(String[] args) {
		System.out.println(1);
	 }
  }

  class [[Foo]] {}

  class [[Foo]] {}
]] 2 errors

test waring on unused class [[
  class Main {
	 public static void main(String[] args) {
		System.out.println(1);
	 }
  }

  class Foo {}

  class [[Foobar]] {
	 Foo x;
  }
]] 1 warning
</verbatim>

<table style="border: 2px solid #D0D0D0; padding: 5px; width: 80%; background-color: #f0f9ff; margin-left:auto; margin-right:auto; border-spacing: 5px"><tr><td>
%T% _Tip:_ An error might result in more then one error message shown in the editor. Thus, think carefully about the right number of errors in a test case.
</td></tr>
</table>

---+++ Testing Transformations

Finally, you can test transformations by specifying the name of a strategy and the expected result in a with =run ... to...= clause. Again, you can mark the relevant part in the program with inner square brackets. For example, the following test case checks the result of applying =type-of= to an expression:

<verbatim>
test type of addition is integer [[
  class Main {
	 public static void main(String[] args) {
		System.out.println([[1+1]]);
	 }
  }
]] run type-of to Int()
</verbatim>

---++ Required Test Cases

---+++ Name Analysis

You need to specify test cases for the resolution of 
	* class names, 
	* field names, 
	* method calls, 
	* parameter names, and 
	* variable names. 
Additionally, you should have test cases for 
	* errors on duplicate definitions, 
	* errors on missing definitions,
	* warnings on unused definitions, 
	* errors on cyclic inheritance, 
	* errors on hiding fields,
	* warnings on hiding variables,
	* errors on overloaded methods,
	* notes on overriding methods, and
	* errors on instantiating or subclassing the main class.

---+++ Type Analysis

You should specify test cases regarding the =type-of= strategy for all kinds of expressions. 
Additionally, you should have test cases for type-related errors in 
	* expressions,
	* statements, and
	* methods.




<!--

---++ Storing Class Declarations

To perform static analysis of class names, you first need to store the class declarations in an environment:

	1. Define a constructor =Classes= of type =Env= for the environment.
	1. Define rewrite rules =store= which match class declarations and store them in the environment. You can find the required strategy =store-declaration(|environment)= in =lib/environment.str=.
	1. Define a strategy =store-all= which traverses an AST and stores all class declarations.
	1. Integrate =store-all= into =editor-analyse= in =trans/minijava.str=.

Now, =store-all= is executed whenever you edit a !MiniJava program. 
To test your strategy and to see the entries stored in the environment, you can add a builder to your editor:

	1. Define a new builder in =editor/MiniJava-Builder.esv=. Here you need to specify the name of a strategy which implements the builder.
	1. Define this strategy in =trans/minijava.str=. See the definition of =generate-aterm= how to match input and construct the output correctly. 
	1. Use the strategy =all-entries= to transform an environment into a list of entries. Though this list is an ATerm, you should choose a different file name than in =generate-aterm=.

---++Projections

You can implement projections as simple rewrite rules. 
On the left hand side of these rules, you match a declaration, e.g. a class declaration, and bind the information you want to project to a variable. 
You can then use this variable on the right hand side of the rule.

Here is an example from the Tiger compiler:

<verbatim>
var-name : VarDec(x, _) -> x
var-name : VarDec(x, _, _) -> x
var-name : For(x, _, _, _) -> x
var-name : FArg(x, _) -> x
</verbatim>

In four rewrite rules, different kinds of variable declarations, i.e. simple variable declarations, variable declarations with initialisation, iterator variables in for loops and function arguments, are mapped to the name of the declared variable. 
Use the same style to implement projections =class-name= and =parent-name= for class declarations. 
You can instrument hover help, to test your projections:
Define a hover for class declarations in =editor/MiniJava-References.esv=. 
See the corresponding generated file for documentation.
Implement the hover strategy. 
Make sure to get the interface of the strategy right. 
Use your projection as the hover text.  

---++ Error Checking

You can  now check the first errors related to class names:

	* undeclared classes
	* multiple class declarations with the same name
	* subclasses of the main class
	* instantiation of the main class
	* main class as a type

Define a rewrite rule =editor-error= for every kind of error and check the constraints in its =where= clause. 

<table style="border: 2px solid #D0D0D0; padding: 5px; width: 80%; background-color: #f0f9ff; margin-left:auto; margin-right:auto; border-spacing: 5px"><tr><td>
%T% _Tip:_ 
The following strategies from =lib/environment.str= might be useful for you:

	* =is-declared(|environment)= succeeds if the given environment contains a declaration with the given name.
	* =lookup-all(|environment)= maps a name to a list of its declarations in the given environment.
	* =lookup-all(test | environment)= maps a name to a list of its declarations in the given environment for which the strategy test is successful.
	* =lookup-first(test | environment)= maps a name to the first declaration in the given environment for which the strategy test is successful.
	* =lookup-unique(|environment)= maps a name to its unique declaration in the given environment. The strategy fails, if the declaration is not unique, i.e. in case of multiple or no declarations.
	* =project-all(projection | environment)= maps a name to a list of elements which are projections of its declarations in the given environment. 
	* =project-first(projection | environment)= maps a name to an element which is the first projection of one of its declarations in the given environment.
	* =all-entries= maps an environment to a list of name-declaration pairs stored in this environment.
	* =all-keys= maps an environment to a list of names stored in this environment.
	* =all-declarations= maps an environment to a list of declarations stored in this environment.
</td></tr>
</table>

Integrate =editor-error= into =editor-analyse= in =trans/minijava.str= and test your implementation.

---++ Editor Warnings
You can now implement editor warnings for unused classes:

	1. Extend store to store not only declarations, but also references. Use =store-reference(|environment)= from =lib/environment.str=.
	1. Define rewrite rules =editor-warning= to check for unused classes. Use =is-referred(|environment)= from =lib/environment.str=.
	1. Hook =editor-warning= into =editor-analyse= in =trans/minijava.str= and test your implementation.

---++ Look-ups

Look-up transformations map names to information about the named element, e.g. a class name to a list of names of its ancestors. 
Since you have only a name, you typically have to get the declaration of the named element. 
Either during or after this step, you project the declaration to the information you are interested in. 

<table style="border: 2px solid #D0D0D0; padding: 5px; width: 80%; background-color: #f0f9ff; margin-left:auto; margin-right:auto; border-spacing: 5px"><tr><td>
%T% _Tip:_ 
Remember, you can use strategies from =lib/environment.str= to look-up or project declarations:
</td></tr>
</table>

Start with implementing a look-up strategy =parent= which maps a class name to the name of its parent. 
If there is no parent, the strategy should fail.

<table style="border: 2px solid #D0D0D0; padding: 5px; width: 80%; background-color: #f0f9ff; margin-left:auto; margin-right:auto; border-spacing: 5px"><tr><td>
%T% _Tip:_ 
You have already a strategy which projects the parent name of a class declaration.
</td></tr>
</table>

Now you can define another look-up strategy =ancestors= which maps a class name to a list of names of its ancestors (including itself) as follows:

<verbatim>
ancestors = rtc(parent) 

rtc(s) = !(<id>, []) ; rec r(elem <+ !(<Fst(); try(s)>, <MkCons>) ; r)
</verbatim>

You can now check for cyclic inheritance. 
Add a corresponding rewrite rule to your error checking.


<table style="border: 2px solid #D0D0D0; padding: 5px; width: 80%; background-color: #fff9f0; margin-left:auto; margin-right:auto; border-spacing: 5px"><tr><td>
%GS% _Challenge:_
Try to come up with an own definition of =ancestors=. 
Do not mimic the implementation of =rtc(s)= but use recursive rewrite rules with an accumulator instead.
</td></tr>
</table>

<table style="border: 2px solid #D0D0D0; padding: 5px; width: 80%; background-color: #fff9f0; margin-left:auto; margin-right:auto; border-spacing: 5px"><tr><td>
%GS% _Challenge:_
Define a look-up strategy =descendants=, which maps a class name to a list of names of its descendants (including itself). 
You should use =ancestors= to find the classes which are descendants.
</td></tr>
</table>
-->