Hi,

When I was adapting KOL for 2.5.1 (trunk) I noticed a delphi incompatibility:

PSomeType = ^TMySomeType;
TMySomeType = tagSometype;

This doesn't compile. I have to change this to

TMySomeType = tagSometype;
PSomeType = ^TMySomeType;

It potentially breaks a lot of code that is syntactically correct for Delphi.

Btw, I have worked around it by changing this for kol.pas by hand.

Is this a documented issue or should I submit a bugreport?

Regards,

Thaddy

Can you please provide an example? The following code compiles for 2.4.0, 2.4.2rc1 and 2.5.1 (from the weekend):

=== source begin ===

program pointertest;
type
   tagSomeType = Integer;
   PSomeType = ^TMySomeType;
   TMySomeType = tagSomeType;
begin
end.

=== source end ===

Regards,
Sven

Is this a documented issue or should I submit a bugreport?

I will try to isolate it. kol.pas is a little fat bastard :)

Small example, 2.5.1 trunk from today

---
program Project2;
{$APPTYPE CONSOLE}
uses windows;
{$DEFINE SHOULD_COMPILE_IN_FPC }  // add dot after "{"
{$IFDEF SHOULD_COMPILE_IN_FPC}
type
   PPValueA = ^TPValueA;
   PPValue = PPValueA;
   pvalueA = packed record
     pv_valuename: PAnsiChar;           { The value name pointer }
     pv_valuelen: BOOL;
     pv_value_context: Pointer;
     pv_type: DWORD;
   end;
   pvalue = pvalueA;
   TPValueA = pvalueA;
   TPValue = TPValueA;
{$ELSE WILL_COMPILE_IN_FPC}
type
   pvalueA = packed record
     pv_valuename: PAnsiChar;
     pv_valuelen: BOOL;
     pv_value_context: Pointer;
     pv_type: DWORD;
   end;
   TPValueA = pvalueA;
   TPValue = TPValueA;
   PPValueA = ^TPValueA;
   PPValue = PPValueA;
   pvalue = pvalueA;
{$ENDIF}
begin
//
end.

I don't know what you're doing wrong, but it compiles here O.o

FPC 2.4.0rc1 and FPC 2.5.1 (built on 07th November 2010). Platform: i386-linux (tested with i386-win32 as well).

I'll update to today's trunk version.

Regards,
Sven

Sven Barth wrote

I'll update to today's trunk version.

Also no error. Would you please send the compiler's output?

Regards,
Sven

2010/11/10 Sven Barth :

Maybe a different mode switch? Add {$mode delphi} to the source?

Vincent

Same (successful) result with the modes "fpc", "objfpc" and "delphi"...

Regards,
Sven

Tnx Sven,

I am tracking it down.
the KOL library is notorious for its complexity with include files and conditionals compiler. It looks like we may have hit a limit somewhere. With a clean build my example indeed compiles in all modes (although KOL should use Mdelphi by default)

Tnx for your efforts, I will report the actual cause of the issue.

Thaddy

Perhaps somewhere a new "type" section begins between the declaration of the pointer ("Foo = ^Bar") and the declaration of the real type ("Bar = XYZ")? This could easily be the case when includes are used and those aren't clean ^^ (e.g. packages\sqlite\src\sqlite.inc had a "end." and the units where it was included as well - there was no error though, because the next instruction after the include in the units was "end." as well)

Regards,
Sven

I'm just preparing an alternative scanner, with (possibly) better handling of include files and directives - the ToDo list already has 15 topics. There an option could be added that included files must not only have complete $ifs (all terminated by according $endifs), but also must have complete block statements - if that really is a useful option.

DoDi