本次美国代写主要为C语言语法分析器

Project 3
Flex & Bison

Project 3
Flex and Bison: Scanner and Parser Generators
The purpose of this project is to introduce scanner and parser generators, as well as get familiar with regular expressions and bottom-up parsing. The Flex scanner generator and the Bison parser generator will be utilized.

Specification and Description Changelog
A list of all the changes made to this project description is below:

No changes yet.
Files
You can find the provided code files required the project in p3.zip.

The scanner definition is contained in the lexer.l file and the parser definition is contained in the parser.y file. The files also include a Makefile which is used to build the project and can also be used to run all provided test cases and a main.cpp file which is the entry point to the program and just calls the parser.

Description
This project consists of writing a specification for a scanner and a bottom-up parser for a given programming language. The specifications will then be used by the scanner generator Flex and parser generator Bison to automatically generate a C scanner and parser.

The language that will be parsed is a simplified object-oriented programming language created for this course. The language has features such as classes, methods, members, statements, and expressions. The full specification of the language is given below in the Language section of this page.

Lexer Specification
You will need to write a Flex specification for all the tokens in the language, which will be used by the parser. A Flex specification is made up of rules, which are a regular expression to match as well as a block of C code that should return a token for that expression. An example Flex rule is:

[ab]*[c-e] { return T_ABCDETOKEN; }
This rule will match zero or more a or b characters followed by a single c, d, or e character. It will return the token called T_ABCDETOKEN. Possible patterns (regular expressions) available for use in Flex are described in the Flex manual Patterns page.
As our language has many kinds of tokens, you will need to write many flex rules to match them all. Each rule should return an appropriate token to be used by the parser. The specification should also ignore and discard comments without returning any token or taking any action in the parser. Finally, it should also catch any invalid characters and output an “invalid character” error. The provided lexer.l file already contains a rule which will match any character and output the appropriate error, all you need to ensure is that this rule is only matched as a last resort (all other rules should be preferred).

Flex will always match the longest possible substring. This means that it would prefer to match the expression [a-z]* over matching [a-z] multiple times. In the case where there are multiple rules that have the same match length, then Flex will always prefer the rule listed first in the specification. Therefore you should order your rules in the same order you want them to be applied. If a given rule can never be matched, Flex will output a warning when you build.

There are other features of Flex which you may find useful for this project. Two specific features that we suggest that you investigate are definitions, which allow you to name a regular-expression for use later as a subexpression, and start conditions, which allow you to move between different possible states and only match certain rules while in certain states.

Parser Specification
You will need to write a Bison specification for the language grammar, which will be used to parse the input. A Bison specification is made of a list of tokens, precedence/associativity specifiers, and a grammar.

The token listing looks like:

%token T_PLUS T_MINUS T_MULTIPLY
%token T_FOR T_IF
There may be multiple tokens per line and there may be multiple lines of tokens.
The precedence/associativity specifiers look like:

%left T_PLUS T_MINUS
%right T_UNARYMINUS