summaryrefslogtreecommitdiff
path: root/TODO
diff options
context:
space:
mode:
authorAdela Vais <adela.vais99@gmail.com>2020-09-26 07:12:42 +0200
committerAkim Demaille <akim.demaille@gmail.com>2020-09-26 08:08:25 +0200
commitf296669c0f23af63716050593865475471054941 (patch)
tree581c91e73048f252dcdb17afa544facf5a8be8cb /TODO
parentde638df10447bde11a2a79c9c3233be1f7c406b6 (diff)
downloadbison-f296669c0f23af63716050593865475471054941.tar.gz
d: change the return value of yylex from int to TokenKind
* data/skeletons/lalr1.d: Change the return value. * examples/d/calc/calc.y, examples/d/simple/calc.y: Adjust. * tests/scanner.at: Adjust. * tests/calc.at (_AT_DATA_CALC_Y(d)): New, extracted from... (_AT_DATA_CALC_Y(c)): here. The two grammars have been sufficiently different to be separated. Still trying to be them together results in a maintenance burden. For the same reason, instead of specifying the results for D and for the rest, compute the expected results with D from the regular case.
Diffstat (limited to 'TODO')
-rw-r--r--TODO15
1 files changed, 4 insertions, 11 deletions
diff --git a/TODO b/TODO
index c692b9f9..8cb1a309 100644
--- a/TODO
+++ b/TODO
@@ -249,21 +249,14 @@ are. Keep the same variable names. If you change the wording in one place,
do it in the others too. In other words: make sure to keep the
maintenance *simple* by avoiding any gratuitous difference.
-** Change the return value of yylex
-Historically people were allowed to return any int from the scanner (which
-is convenient and allows `return '+'` from the scanner). Akim tends to see
-this as an error, we should restrict the return values to TokenKind (not to
-be confused with SymbolKind).
-
-In the case of D, without the history, we have the choice to support or not
-`int`. If we want to _keep_ `int`, is there a way, say via introspection,
-to support both signatures of yylex? If we don't keep `int`, just move to
-TokenKind.
-
** Documentation
Write documentation about D support in doc/bison.texi. Imitate the Java
documentation. You should be more succinct IMHO.
+** yyerrok
+It appears that neither Java nor D support yyerrok currently. It does not
+need to be named this way...
+
** Complete Symbols
The current interface from the scanner to the parser is somewhat clumsy: the
token kind is returned by yylex, but the value and location are stored in