Update README.md

Author: gvanrossum

Tools/cases_generator/README.md

@@ -4,6 +4,7 @@ What's currently here:
 
 - lexer.py: lexer for C, originally written by Mark Shannon
 - plexer.py: OO interface on top of lexer.py; main class: `PLexer`
+- parser.py: Parser for instruction definition DSL; main class `Parser`
 - `generate_cases.py`: driver script to read `Python/bytecodes.c` and
   write `Python/generated_cases.c.h`
 
@@ -18,16 +19,16 @@ The DSL for the instruction definitions in `Python/bytecodes.c` is described
 Note that there is some dummy C code at the top and bottom of the file
 to fool text editors like VS Code into believing this is valid C code.
 
-## A bit about the parsers
+## A bit about the parser
 
-The parser classes use use a pretty standard recursive descent scheme,
+The parser class uses a pretty standard recursive descent scheme,
 but with unlimited backtracking.
 The `PLexer` class tokenizes the entire input before parsing starts.
 We do not run the C preprocessor.
 Each parsing method returns either an AST node (a `Node` instance)
 or `None`, or raises `SyntaxError` (showing the error in the C source).
 
-All parsing methods are decorated with `@contextual`, which automatically
+Most parsing methods are decorated with `@contextual`, which automatically
 resets the tokenizer input position when `None` is returned.
 Parsing methods may also raise `SyntaxError`, which is irrecoverable.
 When a parsing method returns `None`, it is possible that after backtracking
@@ -36,13 +37,3 @@ a different parsing method returns a valid AST.
 Neither the lexer nor the parsers are complete or fully correct.
 Most known issues are tersely indicated by `# TODO:` comments.
 We plan to fix issues as they become relevant.
-
-A particular problem is that we don't know which identifiers are typedefs.
-This makes some parts of the C grammar ambiguous, for example,
-`(x)*y` could be a cast to type `x` of the pointer dereferencing `*y`,
-or it could mean to compute `x` times `y`.
-Similarly, `(x)(y)` could cast `y` to type `x`,
-or call function `x` with argument `y`.
-Our parser currently interprets such cases as casts.
-We will solve this when we need to understand expressions in more detail
-(for example, by providing a list of known typedefs generated by hand).