Write a parser that distinguishes between syntactically correct and incorrect programs written in Dream, as defined in the Dream grammar. The program must parse a Dream source file and report syntax errors (if there are any) in the following form: filename:line,col:error message where filename is the name of the input file and line,col is the approximate location (line and column number) in which the error is found.
If there is a syntactic error in the program, your parser must report at least one error, and if there are no syntactic errors, then your parser should not report any. Note that illegal tokens must continue to be detected by the scanner (these should not be sent to the parser, but should be reported to the user). When the parser completes the processing of your grammar, it must print “xxx errors found”, where xxx is the number of errors detected (lexical and syntactic).
Note well: Although there is no requirement in this phase for your parser to generate parse trees with correct operator precedence and associativity, you should make every effort to ensure that your expression trees are correctly shaped. Otherwise, you will have trouble in the next phase. Use the graphical parse tree view to help you verify that your trees reflect correct operator precedence and associativity.
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 Dream source file to be scanned for tokens, and -ds is an optional debugging output switch:
Test files are provided in the class files in /tests/phase2.
Here’s a quick roadmap to help you get started on Phase 2:
Use the “Your Submission Repository” link at the top of these instructions to create a submission repository for your phase 2 submission. Clone the repository to your computer and copy the dream folder from your phase1 submission into it, replacing the dream folder that is there.
Review the lecture notes on ANTLR Parser Generation. You might also wish to consult the ANTLR Parser Rules specification.
Take a careful look at the /examples/parser project. Note especially the technique used in the grammar to handle multiple precedence levels in expressions, and how to implement the -ds and -dp options and error reporting.
The key to the most efficient development of any software project is to break it down into “bite-size” chunks and tackle it a piece at a time. That’s especially true for writing grammars. If you write a small bit of the grammar, test it, then gradually add more pieces, testing as you go, you’ll have a much better chance of successfully completing this phase without losing your sanctification.
Begin by defining productions for the following nonterminals: <start>, <class>, <var_decl>, <type>. “Stub out” the <expression> nonterminal, perhaps by defining it like this:
expression : INTLIT ;
Then, revise your main() method to invoke the generated parser, write a simple Dream source file that contains only classes with instance variable declarations that use integer literal expressions, and test.
Next, tackle <method_decl> and <argument_decl_list>. Stub out <statement_list>. Generate and test. When that works, do <statement_list> and the various <statement>s. Leave <expression> for last.
For the checkpoint, your parser must successfully parse /tests/phase2/cptestok.dream, and should report a parse error for cptestbad.dream. Create README.md in the dream folder containing a brief report in Markdown that indicates the number of hours you have spent
so far, and lists any known bugs.
The checkpoint is 10% of your grade for phase 2, and may not be submitted late.
Create README.md in 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.