Lots of common syntax errors cause huge cascades of errors due to the parser losing its place in the subsequent input.
When we detect a syntax error, we can take advantage of the variety of block terminating keywords to try to re-synchronize the parser with the block structure of the input. We can also use indentation as a hint in error recovery.
[ ] Global function not terminated with si
[ ] Global property body not terminated with si
[ ] Global property with empty type
[ ] Class, trait or struct not terminated with si
[x] Method not terminated with si
[ ] Method signature incomplete arguments
[ ] Method signature incomplete type
[x] Property body not terminated with si
[x] Attempt to nest a named function inside a global function
[ ] Attempt to nest a named function inside a global property
[x] Attempt to nest a named function inside a method
[ ] Attempt to nest a named function inside a property
[ ] Missing colon between argument name and type
[ ] Variable definition with : but no let
[ ] if with no closing fi
[ ] elif with no expression and/or then
[ ] Orphaned else ... fi block
[ ] Orphaned fi
[ ] for with no od
[ ] while with no od
[ ] do with no od
[ ] Orphaned 'od`
[ ] try with no 'yrt`
[ ] Orphaned 'catch`
[ ] Orphaned 'finally`
[ ] Orphaned yrt
[ ] Missing comma between actual arguments in function call
[ ] Unclosed generic type argument brackets []
[ ] use inside class
Recovery strategies:
Apparently nested functions
When encountering an apparent attempt to nest a named function inside something it may be (and is probably more likely that) the actual error is a missing si on the preceding definition. We can use a simple heuristic to determine which:
If the apparently nested function is indented the same amount as the preceding global definition, it's very likely intended to be a global definition, and the actual error was a missing si
In this case we need to:
Report error for the missing si
Roll back to before the nested function definition
Unwind to the global definition parser
Restart the parser
If the apparently nested function is indented the same amount as the preceding class, trait or struct member, it's very likely intended to be a method
Report error for the missing si
Roll back to before the nested function definition
Unwind to the class/trait/struct parser
Restart the parser
If the apparently nested function is indented more than the enclosing class member, it may be a genuine attempt to nest a named method
Report an error for the wrongly nested named function
Carry on parsing it
But throw away the resulting parse tree
Incomplete function signatures
If we detect the beginning of second function signature when we're parsing function formal arguments or type, then the first function signature is probably incomplete, especially if the first function signature is all on one line and the second signature is on a different line.
Lots of common syntax errors cause huge cascades of errors due to the parser losing its place in the subsequent input.
When we detect a syntax error, we can take advantage of the variety of block terminating keywords to try to re-synchronize the parser with the block structure of the input. We can also use indentation as a hint in error recovery.
sisisisisi:but noletifwith no closingfielifwith no expression and/orthenelse...fiblockfiforwith noodwhilewith nooddowith noodtrywith no 'yrt`yrt[]useinside classRecovery strategies:
Apparently nested functions
When encountering an apparent attempt to nest a named function inside something it may be (and is probably more likely that) the actual error is a missing
sion the preceding definition. We can use a simple heuristic to determine which:If the apparently nested function is indented the same amount as the preceding global definition, it's very likely intended to be a global definition, and the actual error was a missing
siIn this case we need to:siIf the apparently nested function is indented the same amount as the preceding class, trait or struct member, it's very likely intended to be a method
siIf the apparently nested function is indented more than the enclosing class member, it may be a genuine attempt to nest a named method
Incomplete function signatures
If we detect the beginning of second function signature when we're parsing function formal arguments or type, then the first function signature is probably incomplete, especially if the first function signature is all on one line and the second signature is on a different line.