1260 cfg semantic domain lite integrate as analyzer

[fm-117]

This PR focuses on actual integration of CFG/DFA as a new kind of analyzer instead of using NodeDispatcher listeners (which are now totally removed).

Diagnostics need to be improved

• add test for recursive performs
• add test for "out-of-bounds performs"
• add test for incorrect order of paragraphs in a PERFORM THRU (issue New diagnostic : The second paragraph/section of a "PERFORM THRU" statement must be defined after the first paragraph/section #1448)
• add test for invalid ALTER statements
• review diagnostics emitted for IX105A et SG102A samples
  • duplicates ?
  • how to improve messages ?

[smedilol]

The code contains an error:
Line 4[12,12] <30, Error, Semantics> - Semantic error: Statement ' go to b' located at line 10, column 12 prevents this PERFORM statement to reach its exit.

IBM Compiler only reports a warning, because the code can still be executed.
Execution will produce an abend U4038, because there is no goback at the end of paragraph b. But if there is a goback, the execution is ok.
So shall we create an error or a warning? I think it should be a warning to behave like IBM compiler.
We can then ask our users if they want an error. In this case the error could be set as parameter of CLI/LSP (like parameter diagnostic.checkEndAlignment)

For the CFG : the goback statement can never be reached, but the dot file shows otherwise.
Line Block1 -> Block2 should not appear in the dot file.

[fm-117]

Ok to turn this diagnostic into a Warning. Edit: done 916f17c.

About the Block1 to Block2 edge, this edge is created while building the graph. It is only after resolving all GOTO/ALTER/PERFORM that we could find out which part of the code is unreachable or not.
The graph is built as to contain all and every possible paths but we need a post-build analysis to actually find which parts are unreachable. Do you confirm @mayanje ?

[mayanje]

In my opinion this case the error is that the perform goes out of paragraph a and thus the goback will never be executed, but this a consequence of the abend U4038 and not the control flow. So you are right to stay iso with IBM Compiler, it is a warning (a Severe Warning).
The unreachability of the goback instruction can be detected by an abstract interpretation in this case, because we must detect that finally we will face an abend U4038.

[rooksdo]

Is it normal that there's no Block11 declared?

[fm-117]

I don't get the meaning of your question 😕
During parsing, the CFG builder will create new block each time a new sentence is encountered and also when branching is required. After building, blocks may be cloned if they participate in a PERFORM target group. When generating the dot file however, only blocks connected to the root are considered. Some blocks created during parsing may finally not appear in the graph.
Do you think the resulting graph is wrong/missing some elements ?

[rooksdo]

I was checking the tests from the .dot files directly, I was wondering about the numbering as I couldn't see any block11 when block10 and block12 were declared. It's just that it's the only block number that doesn't appear in the .dot file although other empty blocks are still declared (block2, block4...). You probably gave me the answer just above so I'll look again at the graphs. Thanks.

[rooksdo]

As discussed together from analysis on perform loops.
Graph doesn't show loop on block30 for Perform until (as for Perform varying in PerfromNested0)

[fm-117]

This bug shall be adressed in the main PR. I'll copy your comment there.