Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2020-05

Generic method works on Linux, not on Windows?

8 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Joost van der Sluis

Hi all,

I have something strange.

I have a generic function defined as follows:

generic function TJSONRttiStreamClass.CreateObjectFromJSONString<T
(AJSONString: TJSONStringType; ADescriptionTag: string = ''): T;
begin
   Result := nil;
end;

When I call it, like this:

LaunchRequest := FSerializer.specialize
CreateObjectFromJSONString<TDabLaunchRequest>(ACommandText);

Then I get a compiler-error on Windows, while it works on Linux:

csjsonrttistreamhelper.pas(81,1) Error: Wrong number of parameters
specified for call to "$fin$00000037"
When I make the function empty (Remove Result := nil) it compiles.

Any idea what to look for?

Regards,

Joost.

Reply by email

Yuriy Sydorov
to Joost van der Sluis
Joost van der Sluis wrote 21 lines
I have something strange. I have a generic function defined as follows: generic function TJSONRttiStreamClass.CreateObjectFromJSONString<T (AJSONString: TJSONStringType; ADescriptionTag: string = ''): T; begin   Result := nil; end; When I call it, like this: LaunchRequest := FSerializer.specialize CreateObjectFromJSONString<TDabLaunchRequest>(ACommandText); Then I get a compiler-error on Windows, while it works on Linux: csjsonrttistreamhelper.pas(81,1) Error: Wrong number of parameters specified for call to "$fin$00000037" When I make the function empty (Remove Result := nil) it compiles. Any idea what to look for?

Does it happen with the fpc trunk?
If yes, what revision do you use? It looks like an issue with my initial implementation of the $parentfp parameter optimization. "$fin$00000037" is a reference to an internal SEH handler procedure which is a special nested procedure.

The latest trunk for win32 compiles fine the following modified example:

{$mode objfpc}{$H+}
generic function CreateObjectFromJSONString<T>(AJSONString: string; ADescriptionTag: string = ''): T;
begin
   Result := nil;
end;
var
   LaunchRequest: TObject;
begin
   LaunchRequest := specialize CreateObjectFromJSONString<TObject>('qwe');
end.

Yuriy.

Reply by email

Joost van der Sluis
to Yuriy Sydorov

Op 26-05-2020 om 23:36 schreef Yuriy Sydorov:

Show quoted text 5 lines
Does it happen with the fpc trunk? If yes, what revision do you use? It looks like an issue with my initial implementation of the $parentfp parameter optimization. "$fin$00000037" is a reference to an internal SEH handler procedure which is a special nested procedure.

Yes, Trunk, updated last sunday. (And today, didn't help) x86_64

Show quoted text 15 lines
The latest trunk for win32 compiles fine the following modified example: {$mode objfpc}{$H+} generic function CreateObjectFromJSONString<T>(AJSONString: string; ADescriptionTag: string = ''): T; begin   Result := nil; end; var   LaunchRequest: TObject; begin   LaunchRequest := specialize CreateObjectFromJSONString<TObject>('qwe'); end.

It's this project: https://gitlab.freepascal.org/Joost/fpdserver/

And the generic function is defined in:

https://gitlab.freepascal.org/Joost/cerialization

I'll try your code tomorrow. Maybe I can get an easier example.

Regards,

Joost.

Reply by email

Yuriy Sydorov
to Joost van der Sluis
Joost van der Sluis wrote 29 lines
Op 26-05-2020 om 23:36 schreef Yuriy Sydorov: > Does it happen with the fpc trunk? > If yes, what revision do you use? It looks like an issue with my initial implementation of the $parentfp parameter > optimization. "$fin$00000037" is a reference to an internal SEH handler procedure which is a special nested procedure. Yes, Trunk, updated last sunday. (And today, didn't help) x86_64 > The latest trunk for win32 compiles fine the following modified example: > > {$mode objfpc}{$H+} > > generic function CreateObjectFromJSONString<T>(AJSONString: string; ADescriptionTag: string = ''): T; > begin >    Result := nil; > end; > > var >    LaunchRequest: TObject; > begin >    LaunchRequest := specialize CreateObjectFromJSONString<TObject>('qwe'); > end. It's this project: https://gitlab.freepascal.org/Joost/fpdserver/ And the generic function is defined in: https://gitlab.freepascal.org/Joost/cerialization I'll try your code tomorrow. Maybe I can get an easier example.

Thanks for the sources. When I put a generic function in a separate unit, I am able to reproduce the issue. Surprisingly it is not caused by my changes, since it fails even with earlier revisions. I've tested with r44958 and it still fails.
It would be nice if you find the offending revision.

Yuriy.

Reply by email

Sven Barth
to Yuriy Sydorov
Yuriy Sydorov wrote 41 lines
On 27.05.2020 1:01, Joost van der Sluis wrote: > Op 26-05-2020 om 23:36 schreef Yuriy Sydorov: >> Does it happen with the fpc trunk? >> If yes, what revision do you use? It looks like an issue with my >> initial implementation of the $parentfp parameter optimization. >> "$fin$00000037" is a reference to an internal SEH handler procedure >> which is a special nested procedure. > > Yes, Trunk, updated last sunday. (And today, didn't help) x86_64 > >> The latest trunk for win32 compiles fine the following modified >> example: >> >> {$mode objfpc}{$H+} >> >> generic function CreateObjectFromJSONString<T>(AJSONString: string; >> ADescriptionTag: string = ''): T; >> begin >>    Result := nil; >> end; >> >> var >>    LaunchRequest: TObject; >> begin >>    LaunchRequest := specialize >> CreateObjectFromJSONString<TObject>('qwe'); >> end. > > It's this project: https://gitlab.freepascal.org/Joost/fpdserver/ > > And the generic function is defined in: > > https://gitlab.freepascal.org/Joost/cerialization > > I'll try your code tomorrow. Maybe I can get an easier example. Thanks for the sources. When I put a generic function in a separate unit, I am able to reproduce the issue. Surprisingly it is not caused by my changes, since it fails even with earlier revisions. I've tested with r44958 and it still fails. It would be nice if you find the offending revision.

Would you please provide your example that fails? I can't get it to fail...

Regards,
Sven

Reply by email

Yuriy Sydorov
to Sven Barth
Sven Barth wrote 38 lines
Am 27.05.2020 um 00:41 schrieb Yuriy Sydorov: > On 27.05.2020 1:01, Joost van der Sluis wrote: >> Op 26-05-2020 om 23:36 schreef Yuriy Sydorov: >>> Does it happen with the fpc trunk? >>> If yes, what revision do you use? It looks like an issue with my initial implementation of the $parentfp parameter >>> optimization. "$fin$00000037" is a reference to an internal SEH handler procedure which is a special nested procedure. >> >> Yes, Trunk, updated last sunday. (And today, didn't help) x86_64 >> >>> The latest trunk for win32 compiles fine the following modified example: >>> >>> {$mode objfpc}{$H+} >>> >>> generic function CreateObjectFromJSONString<T>(AJSONString: string; ADescriptionTag: string = ''): T; >>> begin >>>    Result := nil; >>> end; >>> >>> var >>>    LaunchRequest: TObject; >>> begin >>>    LaunchRequest := specialize CreateObjectFromJSONString<TObject>('qwe'); >>> end. >> >> It's this project: https://gitlab.freepascal.org/Joost/fpdserver/ >> >> And the generic function is defined in: >> >> https://gitlab.freepascal.org/Joost/cerialization >> >> I'll try your code tomorrow. Maybe I can get an easier example. > > Thanks for the sources. When I put a generic function in a separate unit, I am able to reproduce the issue. > Surprisingly it is not caused by my changes, since it fails even with earlier revisions. I've tested with r44958 and > it still fails. > It would be nice if you find the offending revision. Would you please provide your example that fails? I can't get it to fail...

See the test program and unit attached.

Yuriy.

Reply by email

Sven Barth
to Yuriy Sydorov
Yuriy Sydorov wrote 48 lines
On 29.05.2020 22:36, Sven Barth via fpc-devel wrote: > Am 27.05.2020 um 00:41 schrieb Yuriy Sydorov: >> On 27.05.2020 1:01, Joost van der Sluis wrote: >>> Op 26-05-2020 om 23:36 schreef Yuriy Sydorov: >>>> Does it happen with the fpc trunk? >>>> If yes, what revision do you use? It looks like an issue with my >>>> initial implementation of the $parentfp parameter optimization. >>>> "$fin$00000037" is a reference to an internal SEH handler >>>> procedure which is a special nested procedure. >>> >>> Yes, Trunk, updated last sunday. (And today, didn't help) x86_64 >>> >>>> The latest trunk for win32 compiles fine the following modified >>>> example: >>>> >>>> {$mode objfpc}{$H+} >>>> >>>> generic function CreateObjectFromJSONString<T>(AJSONString: >>>> string; ADescriptionTag: string = ''): T; >>>> begin >>>>    Result := nil; >>>> end; >>>> >>>> var >>>>    LaunchRequest: TObject; >>>> begin >>>>    LaunchRequest := specialize >>>> CreateObjectFromJSONString<TObject>('qwe'); >>>> end. >>> >>> It's this project: https://gitlab.freepascal.org/Joost/fpdserver/ >>> >>> And the generic function is defined in: >>> >>> https://gitlab.freepascal.org/Joost/cerialization >>> >>> I'll try your code tomorrow. Maybe I can get an easier example. >> >> Thanks for the sources. When I put a generic function in a separate >> unit, I am able to reproduce the issue. >> Surprisingly it is not caused by my changes, since it fails even >> with earlier revisions. I've tested with r44958 and it still fails. >> It would be nice if you find the offending revision. > > Would you please provide your example that fails? I can't get it to > fail... See the test program and unit attached.

Thanks, I can reproduce it now. Seems that it *has* to be a method instead of a global function. Hopefully I can now find out the issue...

Regards,
Sven

Reply by email

Sven Barth
to Sven Barth
Sven Barth wrote 52 lines
Am 30.05.2020 um 12:33 schrieb Yuriy Sydorov: > On 29.05.2020 22:36, Sven Barth via fpc-devel wrote: >> Am 27.05.2020 um 00:41 schrieb Yuriy Sydorov: >>> On 27.05.2020 1:01, Joost van der Sluis wrote: >>>> Op 26-05-2020 om 23:36 schreef Yuriy Sydorov: >>>>> Does it happen with the fpc trunk? >>>>> If yes, what revision do you use? It looks like an issue with my >>>>> initial implementation of the $parentfp parameter optimization. >>>>> "$fin$00000037" is a reference to an internal SEH handler >>>>> procedure which is a special nested procedure. >>>> >>>> Yes, Trunk, updated last sunday. (And today, didn't help) x86_64 >>>> >>>>> The latest trunk for win32 compiles fine the following modified >>>>> example: >>>>> >>>>> {$mode objfpc}{$H+} >>>>> >>>>> generic function CreateObjectFromJSONString<T>(AJSONString: >>>>> string; ADescriptionTag: string = ''): T; >>>>> begin >>>>>    Result := nil; >>>>> end; >>>>> >>>>> var >>>>>    LaunchRequest: TObject; >>>>> begin >>>>>    LaunchRequest := specialize >>>>> CreateObjectFromJSONString<TObject>('qwe'); >>>>> end. >>>> >>>> It's this project: https://gitlab.freepascal.org/Joost/fpdserver/ >>>> >>>> And the generic function is defined in: >>>> >>>> https://gitlab.freepascal.org/Joost/cerialization >>>> >>>> I'll try your code tomorrow. Maybe I can get an easier example. >>> >>> Thanks for the sources. When I put a generic function in a separate >>> unit, I am able to reproduce the issue. >>> Surprisingly it is not caused by my changes, since it fails even >>> with earlier revisions. I've tested with r44958 and it still fails. >>> It would be nice if you find the offending revision. >> >> Would you please provide your example that fails? I can't get it to >> fail... > > See the test program and unit attached. Thanks, I can reproduce it now. Seems that it *has* to be a method instead of a global function. Hopefully I can now find out the issue...

Fixed in r45646.

Regards,
Sven

Reply by email