Closed Reinhard-Prehofer closed 6 years ago
Ok, this one is tricky.
055530 DISPLAY '------------------------------------------' 08.01.13
055540- '-------------------------------------' 08.01.13
Currently, the preprocessor is transforming these 2 lines to following 1 line with an invalid literal:
DISPLAY '------------------------------------------'-------------------------------------'
However it should be either (solution 1):
DISPLAY '-------------------------------------------------------------------------------'
or it should be (solution 2):
DISPLAY '------------------------------------------''-------------------------------------'
Why is this: Currently the preprocessor is removing a leading ' or " in the continued line, because the NIST test suite that was used to develop the preprocessor has only line continuation examples such as the following, where in the continued line there is no trailing '
055530 DISPLAY '------------------------------------------ 08.01.13
055540- '-------------------------------------' 08.01.13
I would prefer a solution where the input format is considered. In general all "my" provided samples are host/mainframe based and thus fixed column format: This would eliminate solution one, thus I would opt for solution 2. kind regards
Argh, gets more complicated. NIST test case ST135A shows
043500 IF SORTOUT-NON-KEY-1 NOT EQUAL TO " ST1354.2
043600- " A" GO TO SORT-FAIL-1. ST1354.2
has to be processed to
IF SORTOUT-NON-KEY-1 NOT EQUAL TO " A" GO TO SORT-FAIL-1.
055530 DISPLAY '------------------------------------------' 08.01.13
055540- '-------------------------------------' 08.01.13
has to be processed to
DISPLAY '------------------------------------------''-------------------------------------'
I'll have to search for a solution, that's more robust than number_of_quotes_in_line % 2 == 0
:-)
Ok, added a fix in 2cbdd8eada9fa58c2c66b14ec336c1c9fbe11471. This issue was quite complex, so the commit had to establish data structures for looking back to the last line and ahead to the next line. Based on that, logic had to be implemented, which takes several constellations into account. Hopefully, all relevant constellations are covered. All tests are green.
I'm going to re-test it with the example provided by you in this issue thread. If that file parses successfully, I'm going to close this thread.
However I see, that in #37 you provided a similar issue, which potentially is fixed also by 2cbdd8eada9fa58c2c66b14ec336c1c9fbe11471. I'll check that as part of #37.
Added a passing unit test similar to the one provided by you 047512dee785314430a52ad36aac977d97a91b19.
Thanks again!
YES - thanks, the parser works, though ... (sorry)
Could you possibly add a BLANK between the literals, meaning
display '=======' '================'
instead of currently ('' are next to each other):
display '=======''================'
so that no to quotes appear close to each other => IBM-Compiler does not like that all too much
Ok, no problem. Added in ea1322a1c7b4a203191d21fa0091aefc4ad188ee. Now it is display '=======' '================'
.
There could be other edge cases with a combination of numeric and string literals such as display 1'================'
. I would suggest to wait, whether such cases provoke errors, and fix on demand. The rule set for line indicators is already complex enough :-)
Parsing the attached file leads to the following error