1260 cfg semantic domain lite

[fm-117]

This is a draft PR to discuss all code enhancements/refactorings.

[fm-117]

General code improvements :

• use more explicit names for generic type arguments
• generics
  • instruction type parameterization may be removed as we always use Node to describe instructions
  • the data type is used only for blocks, instead of having the data type in the builder we could specify the type of blocks to be used or even better provide a factory for blocks. The builder would only use a common abstraction of blocks instead of having to deal with parameterized blocks
• accessibility of members
  • use stricter visibility when possible to avoid unproper usages
• ControlFlowGraphBuilder does too much
  • Some methods could be moved into other classes to be closer to the data they manipulate
  • for example: grafting and relocate process could be attached to the BasicBlockForNodeGroup

[fm-117]

ControlFlowGraphBuilder possible improvements

• split into 2 classes
  • one should be responsible for the jumps between builders when entering or leaving program/function
    • would inherit from ProgramClassBuilderNodeListener
    • would override Enter/Exit and forward calls to the other class (calling EnterXXX/LeaveXXX methods with typed node)
  • the other would be responsible for the actual building of a graph for a single program/function
    • contains the EnterXXX/LeaveXXX methods
    • can be the CFG graph itself or a new class
• big switches on CodeElementType are dangerous
  • because some cases are missing (new Cobol V6 statements must be added)
  • try to avoid those big switches
    • factorize into one switch intead of 3
    • use only the cases that are actually handled by the builder and leave the default case with a default behavior that should not break the graph
• make better use of the context
  • introduce an abstraction for DeclarativesContext and MultiBranchContext ?
  • turn the context properties into a Strategy pattern ?

[mayanje]

• generics

  • The Generic implementation should not be removed even if there is only one instantiation using Node. Because a BasicBlock is a generic concept in CFG construction, here it targets Node type, but it can be reused for another kind of Instruction for instance for another language, for another AST.

• The logic of CFG Building belongs to the ControlFlowGraphBuilder not to BasiCBlock instance or Basic Block Group instance. This shall not be changed.

Be carefull Refactoring does not means redesign.

Switch case help me to identifiy what is concerned by CFG graph construction what be can be considered as simple instruction.

Don't forget the first task is to validate CFG construction not to start changing every things.

[fm-117]

This is used to memorize the section or paragraph name in which this block appears, so this can be turned into string ProcedureName.

[mayanje]

This is a general tag having object type, I don't want to give it as meaning ProcedureName out of any context.

[fm-117]

Well actually, the Tag property is defined for the derived class BasicBlockForNode so it already acknowledges a Cobol (or TypeCobol) context because it uses the Node class to describe instructions. In Cobol context I think it makes sense to describe a block with the section or paragraph in which it appears.

[fm-117]

Cobol V6.2 new statements missing.

Naming may be a bit confusing because to determine if a Node is a Statement, we already have the Statement marker interface. This is more like "Is this node a statement that CFG should handle".

[mayanje]

Yes, this is the purpose of the static method: "Is this node that CFG can handle" Because for instance it exists Node without CodeElement, CFG cannot take in account such nodes (like Then, WhenGroup, ...).

[fm-117]

Copied comment from @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]

See rebase version: #1806.