Another small program where the error is clear: there are two level 78 fields with the same name.
In this case, the error is also easy to find.
However, the original program was much longer and more complex, and the fact that there were two fields with the same name (one of them inside a copy file) was not easy to spot.
The problem I want to point out is that the compiler message syntax error, unexpected Literal, expecting Identifier
seems to me completely misleading compared to the real error (a duplicate field).
Have a look at [feature-requests:#464] for the details - in short: the current preparser inserts the recognized literals before the parser sees that, allow easy recognition of type mismatches and optimizations. It could and should be changed, but that's still a work someone needs to be done.
Another small program where the error is clear: there are two level 78 fields with the same name.
In this case, the error is also easy to find.
However, the original program was much longer and more complex, and the fact that there were two fields with the same name (one of them inside a copy file) was not easy to spot.
The problem I want to point out is that the compiler message
syntax error, unexpected Literal, expecting Identifierseems to me completely misleading compared to the real error (a duplicate field).
This is the only compiler message:
C:\OpenCobolIDE\GC20base2\bin\cobc.exe -x -o bin\TEST101.exe -std=default -TGCLISTING.TXT -Wall -Xref -debug -fdebugging-line -fec=EC-ALL -frelax-syntax-checks -fstop-error-statement=ok -ftrace -ftsymbols -free -lpdcurses TEST101.COB
TEST101.COB:9: error: syntax error, unexpected Literal, expecting Identifier
7 | 01 MOUSE-FLAGS PIC 9(04).
8 | 78 SET-AUTO-MOUSE-HANDLING VALUE 1.
9 > 78 SET-AUTO-MOUSE-HANDLING VALUE 1.
10 | PROCEDURE DIVISION.
11 | COMPUTE MOUSE-FLAGS = SET-AUTO-MOUSE-HANDLING
And there are also some undefined fields but this is not reported as an error...
Can anyone give me a feedback on this rather ambiguous compiler message?
Have a look at [feature-requests:#464] for the details - in short: the current preparser inserts the recognized literals before the parser sees that, allow easy recognition of type mismatches and optimizations. It could and should be changed, but that's still a work someone needs to be done.
Related
Wish List: #464