Opened 4 years ago

Last modified 4 years ago

#5966 new defect

Functional argument binding: wrong type mismatch error thrown

Reported by: dariomangoni@… Owned by: lochel
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@… 4 years ago.
MinimalExample
EmbeddedFunctions_default.zip (2.3 KB) - added by dariomangoni@… 4 years ago.
Example using default argument

Download all attachments as: .zip

Change History (7)

Changed 4 years ago by dariomangoni@…

MinimalExample

comment:1 Changed 4 years ago by sjoelund.se

  • Component changed from *unknown* to New Instantiation
  • Owner changed from somebody to perost

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

comment:2 Changed 4 years ago by perost

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 Changed 4 years ago by perost

I opened a ticket for the specification about this here.

comment:4 Changed 4 years ago by dariomangoni@…

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)

Changed 4 years ago by dariomangoni@…

Example using default argument

comment:5 Changed 4 years ago by perost

  • Component changed from New Instantiation to Code Generation
  • Owner changed from perost to lochel

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.