Wrong instantiation of ranges

[Rüdiger Franke]

Consider the following example

model RangeTest
  model Base
    parameter Real p;
  end Base;
  Base[3] b(p = 100.0:100.0:300.0);
end RangeTest;

omc -d=newInst generates:

class RangeTest
  parameter Real b[1].p = 199.0;
  parameter Real b[2].p = 299.0;
  parameter Real b[3].p = 399.0;
end RangeTest;

[Per Östlund]

The new frontend actually just uses:

list(Expression.REAL(r) for r in start.value:step.value:stop.value)

to generate the list, in other words it relies on the code generation to handle it. But it looks like the code generation for a list reduction over a range is broken. I'm guessing NFCeval.evalRange is the only part of the compiler that actually uses them, so that particular path in the code generation has probably not been tested before.

[Rüdiger Franke]

It also appears related to the way the frontend uses the code generation. Look at this extended example. It works for q:

model RangeTest2
  model Base
    parameter Real p;
  end Base;
  Base[3] b(p = 100.0:100.0:300.0);
  parameter Real[3] q = 100.0:100.0:300.0;
end RangeTest2;

omc -d=newInst gives:

class RangeTest2
  parameter Real b[1].p = 199.0;
  parameter Real b[2].p = 299.0;
  parameter Real b[3].p = 399.0;
  parameter Real q[1] = 100.0;
  parameter Real q[2] = 200.0;
  parameter Real q[3] = 300.0;
end RangeTest2;

[Per Östlund]

Replying to rfranke:

It also appears related to the way the frontend uses the code generation. Look at this extended example. It works for q:

Aha, it seems I was too hasty, q is in fact using the code generation path in this case while b is not. The error was actually in the expression subscripting code, a couple of -1 had ended up where they didn't belong. Should be fixed in 2655115.