In the following code, one statement does not compile, probably due to a missing ")" - however, the error message is confusing.
Maybe the message should state the problem better if possible. Thanks.
IDENTIFICATIONDIVISION.PROGRAM-ID.HELLO-WORLD.DATADIVISION.WORKING-STORAGESECTION.01 LBPIC S9(4) COMPVALUE1.01 RBPIC S9(4) COMPVALUE6.01 TXTPIC X(100) VALUE "SOME TEST DATA".01 TXT2PIC X(100) VALUESPACES.PROCEDUREDIVISION.*> THE FOLLOWING STATEMENT DOES NOT COMPILE.*> ERROR MESSAGE IS:*> main.cobc: 14: error: syntax error, unexpected TO, expecting LEADING or TRAILINGMOVEFUNCTIONTRIM(TXT(LB+2 :RB-(LB+2 ))TOTXT2DISPLAYTXT2*> THE FOLLOWING STATEMENT COMPILES WITH NO ERROR MOVEFUNCTIONTRIM(TXT(LB+2:RB-(LB+2)))TOTXT2DISPLAYTXT2STOPRUN.
Last edit: Simon Sobisch 2021-07-20
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hm. The issue here is that without the ")" the parsing of the function goes on, and in the place where the reserved word "TO" currently is it is possible to have
LEADING
TRAILING
end of the function
From a quick glance I've seen no direct way to intercept the error in a reasonable way, all variants I've thought of would remove the two possibly tokens from the message (somewhere I've seen BOTH as a reserved word for example and sometimes people have a typo like LEDING, cobc would then report unexpected WORD, expected LEADING or TRAILING, so that's something that would help in this case.
If someone provides a patch to improve the message I'd apply it, but until then it will stay that way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
Anonymous
-
2021-07-20
I know that it is easy to suggest than actually do but maybe checking the number of "(" and the number of ")" in a sentence can be accomplished before testing for the syntax...Just a thought. Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Theoretically this would be an approach, but as a sentence can be multiple pages long that would like by not that useful, but already useful if extended as "keep a list of each ( that doesn't has a matching ) until a . is found, then check - this way one could explicit have a place where it possibly should be placed at - and could even "assume" that (scanner.l would have to do this and insert a not-seen TOK_PAREN_CLOSE after issuing the error (so the parser has a better option to go on parsing; even better if it is also done if a new reserved word that starts a new sentence is used).
As noted: FR accepted, patches welcome :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the following code, one statement does not compile, probably due to a missing ")" - however, the error message is confusing.
Maybe the message should state the problem better if possible. Thanks.
Last edit: Simon Sobisch 2021-07-20
Hm. The issue here is that without the ")" the parsing of the function goes on, and in the place where the reserved word "TO" currently is it is possible to have
LEADINGTRAILINGFrom a quick glance I've seen no direct way to intercept the error in a reasonable way, all variants I've thought of would remove the two possibly tokens from the message (somewhere I've seen
BOTHas a reserved word for example and sometimes people have a typo like LEDING, cobc would then reportunexpected WORD, expected LEADING or TRAILING, so that's something that would help in this case.If someone provides a patch to improve the message I'd apply it, but until then it will stay that way.
I know that it is easy to suggest than actually do but maybe checking the number of "(" and the number of ")" in a sentence can be accomplished before testing for the syntax...Just a thought. Thank you.
Theoretically this would be an approach, but as a sentence can be multiple pages long that would like by not that useful, but already useful if extended as "keep a list of each
(that doesn't has a matching)until a.is found, then check - this way one could explicit have a place where it possibly should be placed at - and could even "assume" that (scanner.l would have to do this and insert a not-seen TOK_PAREN_CLOSE after issuing the error (so the parser has a better option to go on parsing; even better if it is also done if a new reserved word that starts a new sentence is used).As noted: FR accepted, patches welcome :-)