For fun I made my compiler a bit more robust by looking for common Jack language errors. Here is list of what I've implemented:
-[syntax errors are already caught by the tokenizer/parser, as part of the project.
For example, "var boolean int;" is a syntax error because int is a keyword, and should be an identifier]
-unexpected token after end of class
-class name and file name mismatch
-duplicate variables within the same scope
-duplicate subroutine declaration within the same class
-subroutine not found (if called in a way where it’s expected to be in this class)
-calling a method from within a function, where 'this' is implied
-accessing a field from within a function
-accessing 'this' from within a function
-subroutine call/declaration mismatch (in terms of kind: e.g. called as a method but declared as a function)
-subroutine call/declaration mismatch (in terms of nArgs: e.g, called with 1 arg but declared with 2 args)
-subroutine has no return statement
-return type of a constructor is not of the class type
-a constructor that does not return 'this'
-a non-void subroutine that returns no expression
-a void subroutine that returns an expression
-integer constant exceeds 32767
Most of these were trivial to implement. The errors with regard to subroutine calls matching their declarations -that was more work, but not too bad. Of course, in that case, I only worry about calls that are made to subroutines within the class. I don't check external calls.
I'm sure there are many more errors I could implement. Would love to hear your ideas.
Nice. One type of error common error is to miss a semicolon or a closing curly brace, bracket or parenthesis. This kind of error is harder to pinpoint. The parser normally detects and reports the error a few lines later, which is confusing, especially for less experienced programmers.
I don't know how easy or how hard it would be to do such analysis, but it might be an interesting exercise.