Compiler Design
The viper compiler is a multi-pass compiler, compiling to vipIR code that is then used to generate the object code by the vipIR library. An overview of the design is shown in the flowchart below.
The lexer is the first stage of the viper compiler. It takes viper source code as its input, emitting an array of tokens that represent the source code in a way that the parser is able to interpret. Tokens store information about their kind (e.g. an integer literal, or + operator), raw text, and source information for debugging purposes. If an invalid token is found, the lexer reports this and the compiler exits.
The lexer can be found at framework/include/lexer and framework/src/lexer
The parser is the second stage of the viper compiler. Its input is an array of tokens, usually outputted by the lexer, and it outputs an AST(Abstract Syntax Tree), representing the program without retaining information about the source code, other than for debugging purposes. The parser can report many errors, such as those for invalid program grammar or unknown type names.
The parser can be found at framework/include/parser and framework/src/parser
The typechecker is the stage of the viper compiler that ensures the types of every AST node are valid and that their children nodes have the correct types. It also performs implicit conversions between types, such as adding an i64 and i32 - it would cast the i32 to an i64 to allow the operation to take place.
The typechecker does not exist in a single location, rather it has unique functionality in each AST node, which means that it can be found in the AST node classes.
IR emission is the final stage of the viper compiler. It takes the typechecked AST and converts it into a vipIR module that can be used to generate object code. Very little analysis/checking is done at this stage as it is assumed to have been done in an earlier stage.
The IR emission stage also does not exist in a single location, similar to the typechecker. It can also be found in each of the AST node classes.