[KISEMA-1583] Dataflow regions reserve space for local declarations even if the option is disabled

[fabianheyer]

[Issue KISEMA-1583 migrated from JIRA, first reported on 2020-05-15]

scchart NewSCChart {
//  input bool Z // Enable for second graph
  output signal X
  
  dataflow {
    int Z // disable for second graph
    Z = X
  }
}

For the following graphs, local declarations or declarations are disabled. If this is the case I would expect the drawing to look like the second one.

[NiklasRentzCAU]

I just ran into the same issue and dug around a little:

1. This issue also applies to control flow regions, this is a minimal example where this occurs:

@diagram[declarations] false
scchart declarations2 {
  region:
    int test // uncomment for less reserved space on top.
    initial state A
}

2. This issue is related with the way declaration space is reserved at first, and then removed later if no declarations are present. The DataflowRegionSynthesis checks if declarations are available, if they are, space is reserved for declarations (and actions) in the ControlflowRegionStyles#addStatesAndDeclarationsAndActionsArea method. That defines a DECLARATIONS_CONTAINER, which the DeclarationsHook puts the declarations into if they should be shown. This hook, however, only removes this declarations container and not the entire structure that reserves this additional space, thus leading to the unwanted space.

I got a hacky fix, that not only removes the declarations-specific area, but the entire declarations/actions area like this:

val container = declarations.eContainer.eContainer.eContainer as KContainerRendering
// Hide declarations
if (declarations !== null && container !== null) {
    container.children.removeIf([true])
}

This bases on the knowledge of how the rendering is structured in the synthesis and currently also removes the actions area (which seems to be removed by the "Show Declarations" option anyways)

An alternative fix checking the "SHOW_DECLARATIONS" option in the DataflowRegionSynthesis would cause a cyclic dependency between that class and the hook and therefore also not an ideal solution.