Double input prefix not accepted by the NF

[Francesco Casella]

Please consider the following test model:

package TestInput
connector InputConnector = Modelica.Blocks.Interfaces.RealInput;

model M
  input InputConnector c;
end M;

end TestInput;

When checking with the old front-end, TestInput.M passes the check. With the new FE, instead, the following error is reported:

OMCompiler/build/lib/omlibrary/BuildingSystems 2.0.0-beta/Buildings/Zones/ZoneTemplateAirvolumeMixed.mo:117:3-120:73:writable]
Error: Invalid type prefix 'input' on component airchange, 
due to existing type prefix 'input'.

Is this constraint explicitly mentioned in specification?

This issue affects a large portion of the ​BuildingSystems library, see, e.g., ​BuildingSystems.Buildings.Constructions.Examples.Window

[Per Östlund]

4.5.1 states that a base-prefix on a short class definition is applied to components declared of that type, while 4.4.2.2 states that an input or output prefix is not allowed to be applied to a component that already has one.

A possible loop-hole in 4.4.2.2 is that it says that it applies to structured components, and you could argue that c in this case isn't a structured component. So it's a but fuzzy, and I guess allowing it when the prefixes are the same wouldn't really cause any harm.

[Francesco Casella]

Dymola accepts it. We could of course ask the authors of the BuildingSystems library to remove all those redundant input qualifier, but if you don't see a problem with that, I would rather allow this.

[Per Östlund]

Fixed in 859a2ed.

We now allow the case in the description with a short class declaration, like Dymola does. We don't allow this case though:

model A
  input Real x;
end A;

model M
  input A a;
end M;

It might seem a bit inconsistent, but in that particular case the specification is clear that it's illegal (and Dymola doesn't allow it either).