Perform "definite return analysis"

[ratefuchs]

Each non-void method execution must end with a return, so our compiler must perform a (conservative) analysis. We need to develop rules as to when the compiler has to accept/decline the program.

[ratefuchs]

Currently, my experiments with my javac seem to imply that we can just use a method in statements that return a bool (whether the statement definitly returns) according to the following rules:

Return statement: true Block: any contained statement is true If-then-statement: false If-then-else-statement: (then-part is true) and (else-part is true) While statement: false, except the conditionis "constant true". I need more experiments what constant true meens (and what does not count as constant true). Any other statement: false

[Nidan]

I need more experiments what constant true meens (and what does not count as constant true).

My guess is "constant true" means every expression for which we can determine it to be true at compile time. So we need to evaluate the expression... (Doesn't that belong to optimization?). While somewhat easy if it only consists of (integer and boolean) literals, once identifiers show up things get messy. Where does the language spec draw the line?

I'll implement the basic return check now, we can discuss how far to go with while expressions once we meet

[ratefuchs]

Done in 134a386.

[ratefuchs]

At some time we might check whether we still have differences to javac with regards to this analysis and fix them, but this should be low priority.

[ratefuchs]

Reopened this issue as a reminder; added the label wishlist because it is low priority (as it is not expected of us).