Commit 2372b4a9 authored by Pierre Brandone's avatar Pierre Brandone
Browse files

compiler_stages: tc_2 updated

* source/compiler_stages/tc_2/code_to_write.rst,
* source/compiler_stages/tc_2/goals.rst,
* source/compiler_stages/tc_2/improvements.rst,
* source/compiler_stages/tc_2/tc_2.rst: Here.
parent cb1b8a02
Pipeline #32022 canceled with stage
in 19 seconds
......@@ -14,37 +14,6 @@ src/parse/parsetiger.yy
Supporting object constructs, an improvement suggested for TC-1 (see :ref:`TC-1 Improvements`), is highly
Support metavariable constructs
Augment your scanner and your parser to support the (reserved) keywords :code:`_chunks`, :code:`_exp`,
:code:`_lvalue` and :code:`_namety` and implement the corresponding grammar rules (see
:ref:`Language Extensions` in *Tiger Compiler Reference Manual*). The semantic actions of these productions
shall use the :code:`metavar` function template to fetch the right AST subtree from the :code:`parse::Tweast`
object attached to the parsing context (:code:`parse::TigerParser` instance).
Implement error recovery.
There should be at least three uses of the token :code:`error`. Read the Bison documentation about it.
Use %printer
Extend the use of :code:`%printer` to display non-terminals.
Use %destructor
Use :code:`%destructor` to reclaim the memory bound to semantic values thrown away during error recovery.
Change your skeleton to :code:``, use the :code:`%glr-parser` directive. Thanks to GLR, conflicts
(S/R and/or R/R) can be accepted. Use :code:`%expect` and :code:`%expect-rr` to specify their number.
For information, we have no R/R conflicts, and two S/R: one related to the "big lvalue" issue, and the
other to the implementation of the two :code:`_cast` operators (see :ref:`Additional Syntactic Specifications`
in *Tiger Compiler Reference Manual*).
In order to implement easily the type checking of declarations and to simplify following modules, adjust your
grammar to parse declarations by chunks. The implementations of these chunks are in :code:`ast::FunctionChunk`,
:code:`ast::MethodChunk`, :code:`ast::VarChunk`, and :code:`ast::TypeChunk`; they are implemented thanks to
:code:`ast::Chunk`). Note that an :code:`ast::VarChunk` node appearing in a declaration list shall contain exactly
one :code:`ast::VarDec` object (see :ref:`TC-2 Chunks`); however, an :code:`ast::VarChunk` used to implement a function's formal
arguments may of course contain several ast::VarDec (one per formal).
Implement all methods to create AST nodes on the driver with :code:`make_`
......@@ -12,12 +12,6 @@ Strict Coding Style
Memory Leak Trackers
Using tools such as Valgrind (see :ref:`Valgrind`) to track memory leaks.
Understanding the use of a GLR Parser
The parser should now use all the possibilities of a GLR parser.
Error recovery with Bison
Using the :code:`error` token, and building usable ASTs in spite of lexical/syntax errors.
Using STL containers
The AST uses :code:`std::vector`, :code:`misc::symbol` uses :code:`std::set`.
......@@ -27,9 +21,6 @@ Inheritance
Inclusion polymorphism
An intense use of inclusion polymorphism for :code:`accept`.
Use of constructors and destructors
In particular using the destructors to reclaim memory bound to components.
Use of virtual specifier
Dynamic and static bindings.
......@@ -7,12 +7,13 @@ Possible improvements include:
Resolving all conflicts in your Tiger grammar:
GLR parsers are useful for handling grammars with unresolved conflicts. You
are allowed to leave 2 shift/reduce conflicts in yours, but both of them can
be fixed.
are allowed to leave one shift/reduce conflicts in yours, but it can be fixed.
Therefore, there will be no use for a GLR parser, and you might want to use
a LALR(1) instead.
Desugar Boolean operators and unary minus in concrete syntax
In the original version of the exercise, the | and & operators and the unary minus operator are *desugared*
in abstract syntax (i.e., using explicit instantiations of AST nodes). Using :code:`TigerInput`, you can
in abstract syntax (i.e., using explicit instantiations of AST nodes). Using :code:`TWEAST`, you can
desugar using Tiger's concrete syntax instead. This second solution is advised.
Introduce an Error class
......@@ -8,7 +8,6 @@ TC-2, Building the Abstract Syntax Tree
This section has been updated for EPITA- |class| on 2021-02-21.
At the end of this stage, the compiler can build abstract syntax trees of Tiger programs and pretty-print them.
The parser is now a GLR parser and equipped with error recovery. The memory is properly deallocated on demand.
The code must follow our coding style and be documented, see Coding Style, and Doxygen.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment