Opened 5 years ago
Last modified 5 years ago
#5966 new defect
Functional argument binding: wrong type mismatch error thrown
Reported by: | 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)
Change History (7)
by , 5 years ago
Attachment: | EmbeddedFunctions.zip added |
---|
comment:1 by , 5 years ago
Component: | *unknown* → New Instantiation |
---|---|
Owner: | changed from | to
Marking this as New Instantiation problem. It works without -d=newInst.
comment:2 by , 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:4 by , 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)
comment:5 by , 5 years ago
Component: | New Instantiation → Code Generation |
---|---|
Owner: | changed from | to
It doesn't compile when using the old frontend either, so that seems to be a code generation issue.
MinimalExample