Validation of a function with flexible array dimensions should not given an error message

[gwr]

As reported on ​StackOverflow the following function is perfectly legal Modelica code:

function foo
   input Boolean[:] x;
   output Boolean y;
algorithm
   y := true;
end foo;

Yet, validation raises an error:

[1] 14:27:31 Translation Error
[foo: 2:3-2:42]: Failed to deduce dimension 1 of x due to missing binding equation.

Since this is legal Modelica code, there should simply be a warning message—not an error—that the function cannot be checked and may cause an error if array size cannot be determined at compilation time.

Related: #2276, #1555

[Francesco Casella]

See also #5045.

@perost, can this issue be fixed without too much effort?

[Martin Sjölund]

No, there should be an error message. Just a different one. You cannot check/instantiate *model* on a *function*.

[Francesco Casella]

Replying to sjoelund.se:

No, there should be an error message. Just a different one. You cannot check/instantiate *model* on a *function*.

This is correct from the point of view of developers. Obviously if the check button of OMEdit calls checkModel(), this API call should fail. But this doesn't solve the problem for the end users, who very likely want to be able to check any class, not model, for correctness, including function, records, operator records, as well as entire packages.

The question for @perost would then be: how much effort would it be to

• write a checkClass API function that dispatches the proper operation depending on the type of class, in this case giving an error like "function checking is currently not supported"
• write a checkFunction API function to check that functions are syntactically and semantically correct

In fact, we should decide how to deal with checking of entire packages, which is an essential feature for library developers. One option is to have a checkPackage API function that takes care of it. The other one instead is to have OMEdit use the existing API to recursively figure out the names and categories of classes in a package, much as it alread does to fill in the package browser, and then call the individual checkXXX functions on each of them. This applies to packages, but also, e.g., to models containing functions or other model definitions.

[Per Östlund]

Replying to casella:

The question for @perost would then be: how much effort would it be to

• write a checkClass API function that dispatches the proper operation depending on the type of class, in this case giving an error like "function checking is currently not supported"

I opened ​PR 7119 for it. We used to have a case for functions in checkModel that just skipped the error check, but it was done after the normal case which meant you still would get the error message. I just removed it for now since it wasn't working properly anyway.

• write a checkFunction API function to check that functions are syntactically and semantically correct

That would be far more effort than I have to spend right now, allowing things that are expected to be illegal causes cascading issues.

[Francesco Casella]

See also #5045