Opened 5 years ago

Last modified 5 years ago

#5966 new defect

Functional argument binding: wrong type mismatch error thrown

Reported by: dariomangoni@… Owned by: Lennart Ochel
Priority: normal Milestone: Future
Component: Code Generation Version: v1.16.0-dev
Keywords: Cc:

Description

Taking an example from Modelica Specifications 3.4, pag 151;

OMC reports a bad mismatching while it shouldn't (I think).

[EmbeddedFunctions.quadrature: 5:3-5:49]: Type mismatch in binding integrand = Modelica.Math.sin, expected subtype of integrand<function>(#Real) => #Real, got type Modelica.Math.sin<function>(Real) => Real.

I'm on Win10 and OpenModelica v1.16.0-dev-275-g033f38916 (64-bit)

Attachments (2)

EmbeddedFunctions.zip (1.9 KB ) - added by dariomangoni@… 5 years ago.
MinimalExample
EmbeddedFunctions_default.zip (2.3 KB ) - added by dariomangoni@… 5 years ago.
Example using default argument

Download all attachments as: .zip

Change History (7)

by dariomangoni@…, 5 years ago

Attachment: EmbeddedFunctions.zip added

MinimalExample

comment:1 by Martin Sjölund, 5 years ago

Component: *unknown*New Instantiation
Owner: changed from somebody to Per Östlund

Marking this as New Instantiation problem. It works without -d=newInst.

comment:2 by Per Östlund, 5 years ago

The issue is that the input in the partial function Integrand is named x, while the input in Modelica.Math.sin is named u.

The section that the example comes from states that the provided function must be "function type compatible" to the corresponding formal parameter of function type. According to section 6.5 in the specification this means among other things that the provided function must have the same named inputs and in the same order as in the function type of the formal parameter (and any extra inputs in the provided function must have default bindings).

So as far as I can tell it's not a valid model, but the error message is rather misleading in this case and needs to be improved.

comment:3 by Per Östlund, 5 years ago

I opened a ticket for the specification about this here.

comment:4 by dariomangoni@…, 5 years ago

oh, you are definitely right; having arguments with same name it would be something that I personally would have done so I didn't even think about the possibility that this was the error.

However, even correcting the argument name from x to u it triggers an issue in simulation phase if I actually use the default argument sin:

EmbeddedFunctions.UseQuadratureDefault.c: In function 'EmbeddedFunctions_UseQuadratureDefault_eqFunction_2':
EmbeddedFunctions.UseQuadratureDefault.c:93:112: error: 'boxvar_Modelica_Math_sin' undeclared (first use in this function)
   data->localData[0]->realVars[0] /* area variable */ = omc_EmbeddedFunctions_quadrature(threadData, 0.0, 1.0, boxvar_Modelica_Math_sin);
                                                                                                                ^
EmbeddedFunctions.UseQuadratureDefault.c:93:112: note: each undeclared identifier is reported only once for each function it appears in
<builtin>: recipe for target 'EmbeddedFunctions.UseQuadratureDefault.o' failed
mingw32-make: *** [EmbeddedFunctions.UseQuadratureDefault.o] Error 1
mingw32-make: *** Waiting for unfinished jobs....
mingw32-make: Leaving directory 'C:/WORKSP~1/_MODEL~1/EMBEDD~4.USE'
Compilation process failed. Exited with code 2.

BTW, is failing also in Dymola that complains about the fact that sin has no alorithm and it is not seen as external (eve if it is though).

Doing something wrong? (new attachment)

by dariomangoni@…, 5 years ago

Example using default argument

comment:5 by Per Östlund, 5 years ago

Component: New InstantiationCode Generation
Owner: changed from Per Östlund to Lennart Ochel

It doesn't compile when using the old frontend either, so that seems to be a code generation issue.

Note: See TracTickets for help on using tickets.