Record constructor does not set dependent parameters

[c.schulze@…]

model emptyVector1
  record R
    parameter Integer i = 2;
    parameter Real x[i]=zeros(i);
  end R;
  R r = R(i = 0);
end emptyVector1;

The call to the record constructor should enable the definition of r. But here the size of r.x is [2] and in the constructor [0]. -> incompatible sizes... (OMC r15030)

[Martin Sjölund]

The workaround is (as usual), to not use the record constructor, but rather just modify the record. OMC is a little stupid sometimes.

R r(i=0);

I have not looked closer into the specification. It might be that you should not be able to do this. But from what I have remember, default arguments to functions should be handled specially; and not the way OMC does, i.e. no binding uses a different execution path from with binding.

[Martin Sjölund]

Postponed until 1.9.1

[Martin Sjölund]

This ticket was not closed for 1.9.1, which has now been released. It was batch modified for milestone 1.9.2 (but maybe an empty milestone was more appropriate; feel free to change it).

[Martin Sjölund]

Milestone changed to 1.9.3 since 1.9.2 was released.

[Martin Sjölund]

Moved to new milestone 1.9.4

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Francesco Casella]

As of v1.13.0-dev-672-g87286cb84, the result with the NF is

[1] 00:05:31 Translation Error
[OMCompiler/Compiler/NFFrontEnd/NFRangeIterator.mo: 212:11-213:61]:
Internal error NFRangeIterator.hasNext got invalid range R.i

I don't see this as a critical bug, so I am removing the blocker status. If this affects any existing library, feel free to make it a blocker for 2.0.0 again.

[Francesco Casella]

The NF now reports:

[emptyVector1: 4:5-4:33]: Could not evaluate structural parameter (or constant): r.i 
which gives dimensions of array: x. 
Array dimensions must be known at compile time.

which is a bit odd, as i is obviously as structural parameter. For some reason, it is not recognized as such.

As this issue is most likely not affecting the library coverage, I am postponing it to 2.1.0

[Per Östlund]

Replying to casella:

As this issue is most likely not affecting the library coverage, I am postponing it to 2.1.0

I'm fairly certain it does affect library coverage. There's some similar issues in some libraries (I think BuildingSystems, I don't remember exactly), where the size of a record field depends on another record field. But I don't think it affects the MSL.

[Francesco Casella]

OK. I've set it back to 2.0.0

[Francesco Casella]

Works with -d=newInst using omc v1.14.0-dev-105-g2de3e7582