gnuCOBOL support

[ghost]

This extension looks amazing. After installing I read it can only be used with IBM Enterprise COBOL. Are there any plans to expand support to gnuCOBOL?

The language structure, is pretty much the same, so I'm assuming that it should be fairly easy to support other dialects?

[GitMensch]

See #3 for "known" issue (without the COBOL LSP from Broadcom active you'll get parsing errors) and #8 about the missing code (which would allow others to at least add "external" copybook path's as an optional feature or friendly-fork to allow a version that does not need an LSP).

[GitMensch]

@zimlu02 I guess that can be closed as "won't happen".

[zimlu02]

Hello, supporting other dialects is indeed not a priority at the moment. However, I would keep this issue open.

[Nurkambay]

@GitMensch well, in fact, most of the statements from gnuCOBOL that can affect the graph are supported (PERFORM, GO TO, etc.), so CCF can be used for gnuCOBOL too. If you have any obstacles or errors in the graph, please create an issue for that

[GitMensch]

Nope, my analysis from Feb 2022 seems to still apply

There were multiple issues:

1. The flow cannot be generated if the code contains invalid (or not recognized) COBOL (as seen in the picture there were place holders, but the "structure" (DIVISIONs, SECTIONs) is correct - an approach to skip all things from the first unrecognized character(here a {) to the next line (keeping the line as an "error" token, if necessary) or until the next valid line is found would help with this (this part may be moved out to a different issue for clarity).

2. Main issue: Ensure that there is never only a "general" message like "Failed to generate flow" - at least add a note to check details in the log and actually log to the extension host directly (or an own output view) [or at least provide the "how to get the details" part in a wiki entry and reference this in the message].

3. support for more COBOL dialects - this would likely be something for the LSP, too - but a "water approach" to just skip the not recognized lines as outlined in 1 would solve most of this for CCF, too.

Just checked with a simple source I've happen to have opened and getting the following warning (which possibly should be an error instead):

Could not generate graph due to syntax errors in COBOL file

Checking the problems pane:

[{
    "resource": "/C:/Users/me/test/TESTNUM1.CBL",
    "owner": "_generated_diagnostic_collection_name_#1",
    "severity": 8,
    "message": "Syntax error on '78'",
    "source": "COBOL Language Support (parsing)",
    "startLineNumber": 10,
    "startColumn": 8,
    "endLineNumber": 10,
    "endColumn": 10
}]

happening on

       78 COMPARE      VALUE     'COMPARE_DISPLAY_TO_DISPLAY2'.

Adjusted this to level 77 (implied pic) got

[{
    "resource": "/C:/Users/me/test/TESTNUM1.CBL",
    "owner": "_generated_diagnostic_collection_name_#1",
    "severity": 8,
    "message": "A \"PICTURE\" or \"USAGE INDEX\" clause was not found for elementary item COMPARE",
    "source": "COBOL Language Support (parsing)",
    "startLineNumber": 10,
    "startColumn": 11,
    "endLineNumber": 10,
    "endColumn": 18
},{
    "resource": "/C:/Users/me/test/TESTNUM1.CBL",
    "owner": "_generated_diagnostic_collection_name_#1",
    "severity": 8,
    "message": "A \"PICTURE\" or \"USAGE INDEX\" clause was not found for elementary item TMP-DOUBLE",
    "source": "COBOL Language Support (parsing)",
    "startLineNumber": 20,
    "startColumn": 16,
    "endLineNumber": 20,
    "endColumn": 26
},{
    "resource": "/C:/Users/me/test/TESTNUM1.CBL",
    "owner": "_generated_diagnostic_collection_name_#1",
    "severity": 8,
    "message": "Syntax error on 'BINARY-DOUBLE'",
    "source": "COBOL Language Support (parsing)",
    "startLineNumber": 20,
    "startColumn": 44,
    "endLineNumber": 20,
    "endColumn": 57
},{
    "resource": "/C:/Users/me/test/TESTNUM1.CBL",
    "owner": "_generated_diagnostic_collection_name_#1",
    "severity": 8,
    "message": "A \"PICTURE\" or \"USAGE INDEX\" clause was not found for elementary item TMP-MILLISECONDS",
    "source": "COBOL Language Support (parsing)",
    "startLineNumber": 21,
    "startColumn": 16,
    "endLineNumber": 21,
    "endColumn": 32
},{
    "resource": "/C:/Users/me/test/TESTNUM1.CBL",
    "owner": "_generated_diagnostic_collection_name_#1",
    "severity": 8,
    "message": "Extraneous input 'BINARY-LONG'",
    "source": "COBOL Language Support (parsing)",
    "startLineNumber": 21,
    "startColumn": 44,
    "endLineNumber": 21,
    "endColumn": 55
}]

on

       77 COMPARE      VALUE     'COMPARE_DISPLAY_TO_DISPLAY2'.
       77 ANSWER       PIC X.
       77 NUM-FLD      PIC S9(35)v9.

       01 FLD-X7.
      *  03 FLD-97     PIC S9(5)v9(32).
         03 FLD-97     PIC S9(02)V9(35).
      *  03 FLD-97     PIC  9(3)           SIGN LEADING SEPARATE.

       01  TMP.
           05  TMP-DOUBLE                  BINARY-DOUBLE UNSIGNED.
           05  TMP-MILLISECONDS            BINARY-LONG.
           05  TMP-DISPLAY-LONG            PIC ZZZ,ZZZ,ZZZ,ZZZ,ZZZ,ZZ9.

then tested with a copybook, got the info:

Cannot retrieve outline tree because file was treated as a copybook

and then again the warning:

Could not generate graph due to syntax errors in COBOL file

The biggest issue is that there's no "water" approach but a full parsing, and if there's any issue in this parsing then the CCF does not work at all. It is therefore not only GnuCOBOL related (@Nurkambay I guess this is why you've sent me a ping?) but "any dialect but plain IBM Enterprise COBOL".

... and: the CCF also does not work with a syntax error like "variable not defined" (typo), which is not control-flow statement related ad therefore should be ignored for generating the CCF.