codegen error if one is using Modelica.Utilities.Streams.readLine

[Willi Braun]

Models that try to use the function Modelica.Utilities.Streams.readLine are failing with a code generation error.

model test
/*
function readL
  input String fileName;
  input Integer line;
  output String string;
algorithm
  string := Modelica.Utilities.Streams.readLine(fileName, line);
end readL;

function readF
  input String fileName;
  output String stringVector[Modelica.Utilities.Streams.countLines(fileName)];
algorithm
  for i in  1:size(stringVector, 1) loop
    stringVector[i] := readL(fileName, i);
  end for;
  Modelica.Utilities.Streams.close(fileName);
end readF;
*/
  parameter String fileName = \"./test.txt\";
  parameter Integer N = Modelica.Utilities.Streams.countLines(fileName);
  parameter String file[N] = Modelica.Utilities.Streams.readFile(fileName);
  // works 
  // parameter String file[N] = readF(fileName);

end test;

Somehow the types of an array inside of DAE.STMT_TUPLE_ASSIGN are not generate correct. That code the is generated with the following line works, but then we get other issue. The question is which type should passed to the function contextArrayReferenceCrefAndCopy.

Compiler/Template/CodegenC.tpl

@@ -4734 +4736 @@
   match ty
     case T_ARRAY(__) then
       let &varCopyAfter = buffer ""
-      let var = tempDecl("base_array_t", &varDecls)
+      let var = tempDecl(expTypeArrayIf(ty), &varDecls)
       let lhs = writeLhsCref(e, var, context, &varCopyAfter, &varDecls, &auxFunction)
       let &varCopy += if lhs then '<%lhs%><%\n%>' else error(sourceInfo(), 'Got empty statement from writeLhsCref(<%printExpStr(e)%>)')
       let &varCopy += varCopyAfter
@@ -7070 +7081 @@
 case STMT_TUPLE_ASSIGN(exp=CALL(attr=CALL_ATTR(ty=T_TUPLE(tupleType=ntys)))) then
   let &preExp = buffer ""
   let &postExp = buffer ""
   let lhsCrefs = (List.rest(expExpLst) |> e => match e
     case ARRAY(array={})
     case CREF(componentRef=WILD(__)) then ", NULL"
-    case CREF(componentRef=cr,ty=ty) then (", &" + contextArrayReferenceCrefAndCopy(cr, e, ty, context, varDecls, postExp, &auxFunction))
+    case CREF(componentRef=cr,ty=ty) then (", &" + contextArrayReferenceCrefAndCopy(cr, e, crefLastType(cr), context, varDecls, postExp, &auxFunction))
     // Crazy DAE.CALL on lhs? Yup, we apparently generate those. TODO: Don't generate those crazy things!
     case CALL(attr=CALL_ATTR(ty=ty)) then (", &" + contextArrayReferenceCrefAndCopy(makeUntypedCrefIdent("#error"), e, ty, context, varDecls, postExp, auxFunction))
     else error(sourceInfo(), 'Unknown expression to assign to: <%printExpStr(e)%>'))
   // The tuple expressions might take fewer variables than the number of outputs. No worries.
   let lhsCrefs2 = lhsCrefs + List.fill(", NULL", intMax(0,intSub(listLength(ntys),listLength(expExpLst))))
   let ret = daeExpCallTuple(exp, lhsCrefs2, context, &preExp, &varDecls, &auxFunction)
   let &preExp += match expExpLst
     case ARRAY(array={})::_
     case CREF(componentRef=WILD(__))::_ then '<%ret%>;<%\n%>'
-    case (e as CREF(componentRef=cr,ty=ty))::_ then '<%contextArrayReferenceCrefAndCopy(cr, e, ty, context, varDecls, postExp, auxFunction)%> = <%ret%>;<%\n%>'
+    case (e as CREF(componentRef=cr,ty=ty))::_ then '<%contextArrayReferenceCrefAndCopy(cr, e, crefLastType(cr), context, varDecls, postExp, auxFunction)%> = <%ret%>;<%\n%>'
     // Crazy DAE.CALL on lhs? Yup, we apparently generate those. TODO: Don't generate those crazy things!
     case (e as CALL(attr=CALL_ATTR(ty=ty)))::_ then '<%contextArrayReferenceCrefAndCopy(makeUntypedCrefIdent("#error"), e, ty, context, varDecls, postExp, auxFunction)%> = <%ret%>;<%\n%>'
     case e::_ then error(sourceInfo(), 'Unknown expression to assign to: <%printExpStr(e)%>')
   ('/* tuple assignment */<%\n%>' + preExp + postExp)
 case STMT_TUPLE_ASSIGN(exp=MATCHEXPRESSION(__)) then
   let &preExp = buffer ""
   let &afterExp = buffer ""

[Martin Sjölund]

I believe my working copy will solve the model. But it won't solve the underlying problem that tuple statements assigning to arrays sometimes fail (the fix optimizes the tuple assignment into a regular assignment).
Changing to crefLastType(cr) does not take subscripts into account. Maybe that was the problem.

[Willi Braun]

I also played with crefTypeConsiderSubs(cr) but also without luck.

Do you have ideas how to solve the the underlying problem at all?
Otherwise your working copy would help users anyway.

[Martin Sjölund]

I am just having one problem before I can commit: a function that should not be inlined suddenly is...

Instead of:
C[1,1] = (inv({{1.0, 0.0, 0.0}, {0.0, 1.0, 0.0}, {0.0, 0.0, 1.0}}) * {{1.0, 0.0, 0.0}, {0.0, 1.0, 0.0}, {0.0, 0.0, 1.0}})[1, 1]
I get:
C[1,1] = (LAPACK.dgetri(LU, pivots)[1] * {{1.0, 0.0, 0.0}, {0.0, 1.0, 0.0}, {0.0, 0.0, 1.0}})[1, 1]

But LU and pivots are local variables from the function. And the types on them are wrong, so the array can not be created.

[Martin Sjölund]

I will be busy writing Modrio documents for some time. I could give the code to someone if they want to play with it.

[Willi Braun]

In the model above I found a solution that works for now for the user, so I think it's not that urgent.