Compiler front-end fails if a records instantiates a record from another package

[Michael Wetter]

The OpenModelica front-end fails to parse models that use a record, say A, that instantiates a record of class B if B is not in the same package as A.

This causes all heat transfer models through walls, floors etc in the Buildings library to not translate.

For example, the Buildings library uses in the model Buildings.HeatTransfer.Examples.ConductorMultiLayer the record
Buildings.HeatTransfer.Data.OpaqueConstructions.Insulation100Concrete200.

This record is implemented as

record Insulation100Concrete200 =
    Buildings.HeatTransfer.Data.OpaqueConstructions.Generic (
      material={Solids.InsulationBoard(x=0.1),
                Solids.Concrete(x=0.2)},
                final nLay=2) 
  "Construction with 100 mm insulation and 200 mm concrete";

The record
Buildings.HeatTransfer.Data.OpaqueConstructions.Generic is implemented as

record Generic "Thermal properties of opaque constructions"
...
  parameter Buildings.HeatTransfer.Data.BaseClasses.Material material[nLay] 
    "Layer by layer declaration of material, starting from outside to room-side"
    annotation (choicesAllMatching=true, Evaluate=false, Placement(transformation(extent={{60,60},{80,80}})));
...

The problem is that material is declared in the package BaseClasses.Material. If Buildings.HeatTransfer.Examples.ConductorMultiLayer is simulated, it fails with

In file included from Buildings.HeatTransfer.Examples.ConductorMultiLayer.c:19:
./Buildings.HeatTransfer.Examples.ConductorMultiLayer_functions.h:41:3: error: unknown type name 'Buildings_HeatTransfer_Data_BaseClasses_Material_array'
  Buildings_HeatTransfer_Data_BaseClasses_Material_array _material;
  ^

If I move
Buildings.HeatTransfer.Data.BaseClasses.Material
to
Buildings.HeatTransfer.Data.OpaqueConstructions.Material
so that it is in the same package as Buildings.HeatTransfer.Data.OpaqueConstructions.Generic, then the model translates.
Unfortunately, renaming this record is not a solution as
Buildings.HeatTransfer.Data.Resistances.Generic
also extends from Buildings.HeatTransfer.Data.BaseClasses.Material and hence models that use Buildings.HeatTransfer.Data.Resistances.Generic will fail to translate.

In what time frame would it be possible to fix this in OpenModelica? This is a blocker that prevents many models from working with OpenModelica, and I don't see a solution for how we can fix this in the Buildings library without corrupting the design of the Data package (and causing incompatibilities).

[Adrian Pop]

Yeah, record constants are handled badly. I'm working on a fix for this.
It is similar to #2858

[Martin Sjölund]

This one should be simple to fix. The required header is in the generated code. It just needs to be generated in the correct order in order for C to be happy. A topological sort should do the trick.

It does not relate to record constants.

[Martin Sjölund]

Fixed in r22760.