Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Serguei TARASSOV
Hello,

Sorry, my previous example was not complete.
Here is a problem detected when compiling UniDAC 6.2.8.
Taken from real code in VirtualTable.pas

program Project1;

{$MODE DELPHI}

uses
  SysUtils, Classes, DB;

procedure InternalCreateFieldDefs(Fields: TFields; FieldDefs: TFieldDefs);
var
  F: TField;
  FieldDef: TFieldDef;
begin
  begin
    with F do
    begin
      FieldDef := FieldDefs.AddFieldDef;
      // in FPC 3.0.0 Error: No member is provided to access property
      // in FPC 2.6.4 compiles OK
    end;
  end;
end;

begin
end.
--
Regards,
Serguei
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Michael Van Canneyt


On Tue, 23 Feb 2016, Serguei TARASSOV wrote:

> Hello,
>
> Sorry, my previous example was not complete.
> Here is a problem detected when compiling UniDAC 6.2.8.
> Taken from real code in VirtualTable.pas
>
> program Project1;
>
> {$MODE DELPHI}
>
> uses
>  SysUtils, Classes, DB;
>
> procedure InternalCreateFieldDefs(Fields: TFields; FieldDefs: TFieldDefs);
> var
>  F: TField;
>  FieldDef: TFieldDef;
> begin
>  begin
>    with F do
>    begin
>      FieldDef := FieldDefs.AddFieldDef;
>      // in FPC 3.0.0 Error: No member is provided to access property
>      // in FPC 2.6.4 compiles OK

The problem is in your code and the use of WITH, as I surmised in my
previous mail.

In 2.6.4, FieldDef is resolved to the LOCAL VARIABLE FieldDef.
The code compiles ok.

In 3.0.0, FieldDef is a NEW READ-ONLY property in TField.
Because of the WITH, the compiler resolves FieldDef to this property, but it
is read-only, an so it gives an error.

Change your code to

Var
    AFieldDef: TFieldDef;

and

      AFieldDef := FieldDefs.AddFieldDef;

and all will be well.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Serguei TARASSOV
Michael Van Canneyt wrote
The problem is in your code and the use of WITH, as I surmised in my
previous mail.

In 2.6.4, FieldDef is resolved to the LOCAL VARIABLE FieldDef.
The code compiles ok.

In 3.0.0, FieldDef is a NEW READ-ONLY property in TField.
Because of the WITH, the compiler resolves FieldDef to this property, but it
is read-only, an so it gives an error.
I see, but it's not my code, its a code of the big third-party framework that is working well with all version of Delphi/C++ builder and Lazarus 1.x with FPC 2.6.4.
You cannot recommend them to change code.
There are many other errors during compile, if someone is interesting I can provide the list.

So the problem is in DB unit.
The mode Delphi is declared.
It should be compatible.
--
Regards,
Serguei
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Michael Van Canneyt


On Tue, 23 Feb 2016, Serguei TARASSOV wrote:

> Michael Van Canneyt wrote
>> The problem is in your code and the use of WITH, as I surmised in my
>> previous mail.
>>
>> In 2.6.4, FieldDef is resolved to the LOCAL VARIABLE FieldDef.
>> The code compiles ok.
>>
>> In 3.0.0, FieldDef is a NEW READ-ONLY property in TField.
>> Because of the WITH, the compiler resolves FieldDef to this property, but
>> it
>> is read-only, an so it gives an error.
>
> I see, but *it's not my code*, its a code of the big third-party framework
> that is working well with all version of Delphi/C++ builder and Lazarus 1.x
> with FPC 2.6.4.
> You cannot recommend them to change code.

If course I can, I just did.

> The mode Delphi is declared.

The mode is entirely irrelevant.

> It should be compatible.

We introduced the FieldDef property in TField.
This was a conscious decision.

They chose to use "with", and then this kind of thing can happen at any point.
So, they must adapt their code. Don't use "with" if you're not prepared to deal with such issues.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Graeme Geldenhuys-6
In reply to this post by Serguei TARASSOV
On 2016-02-23 10:54, Serguei TARASSOV wrote:
> I see, but *it's not my code*, its a code of the big third-party framework
> that is working well with all version of Delphi/C++ builder and Lazarus 1.x
> with FPC 2.6.4.

Well, now it doesn't work with FPC 3.0. ;-)


> You cannot recommend them to change code.

Why not. Many 3rd party libraries need to update there code for newer
Delphi and FPC releases. This is just one of those cases. This is not
ever limited to the Object Pascal language, it affects any programming
language.

Plus, it's another excellent example of why you shouldn't use WITH. I
don't care how many disagree with me, I always thought it a bad language
design.

Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Michael Van Canneyt


On Tue, 23 Feb 2016, Graeme Geldenhuys wrote:

> On 2016-02-23 10:54, Serguei TARASSOV wrote:
>> I see, but *it's not my code*, its a code of the big third-party framework
>> that is working well with all version of Delphi/C++ builder and Lazarus 1.x
>> with FPC 2.6.4.
>
> Well, now it doesn't work with FPC 3.0. ;-)
>
>
>> You cannot recommend them to change code.
>
> Why not. Many 3rd party libraries need to update there code for newer
> Delphi and FPC releases. This is just one of those cases. This is not
> ever limited to the Object Pascal language, it affects any programming
> language.

Exactly.

See e.g. the recent changes in TPoint, which necessitated a lot of changes
in the LCL, because "with" was used a lot.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Serguei TARASSOV
Okay, okay, I see.

For info, the indicated error is not critical because of its visibility at compile-time.

All other codes inside "with" statement like
x := FieldDef;
will be compiled without errors and should be checked.

Thank you, guys, for a good compatibility support and adding the features to the principal units that break the existing code of "real world programs".
--
Regards,
Serguei
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Jonas Maebe-2

Serguei TARASSOV wrote on Tue, 23 Feb 2016:

> Thank you, guys, for a good compatibility support

Come on. The only way this kind of problems can be avoided is by us  
never adding any new field or property to any class, ever.

It would probably be useful if we added support to the compiler to  
generate a warning (or even error) in case a with statement hides an  
existing symbol in scope though.


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Michael Van Canneyt
In reply to this post by Serguei TARASSOV


On Tue, 23 Feb 2016, Serguei TARASSOV wrote:

> Okay, okay, I see.
>
> For info, the indicated error is not critical because of its visibility at
> compile-time.
>
> All other codes inside "with" statement like
> x := FieldDef;
> will be compiled without errors and should be checked.
>
> Thank you, guys, for a good compatibility support and adding the features to
> the principal units that break the existing code of "real world programs".

I hope you will send the same mail to embarcadero/Idera.
When they added methods to TPoint, they broke have the VCL code ?

To avoid this, we would need to freeze the code as soon as it is released.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Henry Vermaak
In reply to this post by Jonas Maebe-2
On Tue, Feb 23, 2016 at 02:13:52PM +0100, Jonas Maebe wrote:
> It would probably be useful if we added support to the compiler to
> generate a warning (or even error) in case a with statement hides an
> existing symbol in scope though.

Yes, please.  Something like -Wshadow would be very useful.

Henry
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Jonas Maebe-2

Henry Vermaak wrote on Tue, 23 Feb 2016:

> On Tue, Feb 23, 2016 at 02:13:52PM +0100, Jonas Maebe wrote:
>> It would probably be useful if we added support to the compiler to
>> generate a warning (or even error) in case a with statement hides an
>> existing symbol in scope though.
>
> Yes, please.  Something like -Wshadow would be very useful.

That already exists and is enabled by default for local variables and  
parameter names hiding fields. It even gives errors in FPC and ObjFPC  
modes, rather than warnings. It's just not (yet) implemented for  
with-statements (and local variables or fields hiding global  
variables, but that's a different matter).


Jonas
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Snorkl e
In reply to this post by Serguei TARASSOV

I have the latest version of Devart pgdac and virtualtable.pas compiles fine.

On Feb 23, 2016 3:33 AM, "Serguei TARASSOV" <[hidden email]> wrote:
Hello,

Sorry, my previous example was not complete.
Here is a problem detected when compiling UniDAC 6.2.8.
Taken from real code in VirtualTable.pas

program Project1;

{$MODE DELPHI}

uses
  SysUtils, Classes, DB;

procedure InternalCreateFieldDefs(Fields: TFields; FieldDefs: TFieldDefs);
var
  F: TField;
  FieldDef: TFieldDef;
begin
  begin
    with F do
    begin
      FieldDef := FieldDefs.AddFieldDef;
      // in FPC 3.0.0 Error: No member is provided to access property
      // in FPC 2.6.4 compiles OK
    end;
  end;
end;

begin
end.




-----
--
Regards,
Serguei
--
View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Mark Morgan Lloyd-5
In reply to this post by Graeme Geldenhuys-6
Graeme Geldenhuys wrote:

> On 2016-02-23 10:54, Serguei TARASSOV wrote:
>> I see, but *it's not my code*, its a code of the big third-party framework
>> that is working well with all version of Delphi/C++ builder and Lazarus 1.x
>> with FPC 2.6.4.
>
> Well, now it doesn't work with FPC 3.0. ;-)
>
>
>> You cannot recommend them to change code.
>
> Why not. Many 3rd party libraries need to update there code for newer
> Delphi and FPC releases. This is just one of those cases. This is not
> ever limited to the Object Pascal language, it affects any programming
> language.

And the extra typechecks etc. mean that FPC is a bit better than most
language implementations at catching things like that.

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Graeme Geldenhuys-6
On 2016-02-23 14:13, Mark Morgan Lloyd wrote:
> And the extra typechecks etc. mean that FPC is a bit better than most
> language implementations at catching things like that.

Exactly. I prefer getting an error so I can fix my code and know it will
work as intended - instead of the compiler silently working around the
problem and possibly producing incorrect result (only noticed months
down the line).


Regards,
  - Graeme -

--
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://fpgui.sourceforge.net/

My public PGP key:  http://tinyurl.com/graeme-pgp
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Serguei TARASSOV
This post was updated on .
In reply to this post by Michael Van Canneyt
Michael Van Canneyt wrote
I hope you will send the same mail to embarcadero/Idera.
When they added methods to TPoint, they broke have the VCL code ?

To avoid this, we would need to freeze the code as soon as it is released.
Compared with Unicode migration, introducing the methods into records is not breaking :)

The code is not frozen but for the core level units the modifications are rare and very risky without vast codebase and testing.
DB is a very mature unit, almost all DACs based on it so 100% compatibility with Delphi does matter.
However, there are some useful methods to extend:
- subclassing (the safest)
- class helpers
- property/method's attributes (need to be introduced at compiler level)
- interfaces (when creating new interface for every extension)

I.e. adding attribute "new" to property/method the compiler will generate the error when conflicting to resolve names in existing code.

There is no perfect way so why the language extension is the safest (remember recent discussion about IfThen pseudo-function).
 
--
Regards,
Serguei
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Sven Barth-2
On 23.02.2016 17:21, Serguei TARASSOV wrote:
> Michael Van Canneyt wrote
>> I hope you will send the same mail to embarcadero/Idera.
>> When they added methods to TPoint, they broke have the VCL code ?
>>
>> To avoid this, we would need to freeze the code as soon as it is released.
>
> Compared with Unicode migration, introducing the methods into records is not
> breaking :)

Adding methods to the TPoint or TRect record is *exactly* like adding a
method/property to TField. If you use "with" you might find yourself in
a dangerous/problematic situation. That *did* happen with various code
after we introduced the new methods to TPoint and TRect.

> The code is not frozen but for the core level units the modifications are
> rare and very risky without vast codebase and testing.
> DB is a vary mature unit, almost all DACs based on it so 100% compatibility
> with Delphi does matter.

And the DB code is Delphi compatible. But if you (as in "general you")
are using a feature that is *known* to lead to problems if fields and
properties are added then that's your own problem. From great power
comes great responsibility. We take backwards compatibility very
serious, but there has to be a line drawn somewhere.

> However, there are some useful methods to extend:
> - subclassing (the safest)
> - class helpers
> - property/method's attributes (need to be introduced at compiler level)
> - interfaces (when creating new interface for every extension)

And to burden everyone else with the need to e.g. include a unit with a
helper restricting them from adding their own if they don't derive from
the original helper? No thank you. We are no slaves to Delphi.

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Mark Morgan Lloyd-5
In reply to this post by Serguei TARASSOV
Serguei TARASSOV wrote:

> There is no perfect way so why the language extension is the safest
> (remember recent discussion about IfThen pseudo-function).

More relevant to your situation, I remember discussion about adding an
identifier to WITH to use as an explicit shortcut, i.e. something like

with foo= bar do
   foo.someField := ...

--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Sven Barth-2

Am 23.02.2016 23:28 schrieb "Mark Morgan Lloyd" <[hidden email]>:
>
> Serguei TARASSOV wrote:
>
>> There is no perfect way so why the language extension is the safest
>> (remember recent discussion about IfThen pseudo-function).
>
>
> More relevant to your situation, I remember discussion about adding an identifier to WITH to use as an explicit shortcut, i.e. something like
>
> with foo= bar do
>   foo.someField := ...
>

What would really help here would be the warning that Jonas mentioned...
For the above you could just use a local variable and be done with it. No need to try to "fix" the with-statement.

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Bo Berglund
On Tue, 23 Feb 2016 23:58:37 +0100, Sven Barth
<[hidden email]> wrote:
>
>What would really help here would be the warning that Jonas mentioned...
>For the above you could just use a local variable and be done with it. No
>need to try to "fix" the with-statement.

I really fully agree!
When working a few years back I had to trace through a piece of code
where the original author had done something like:

with My.Stuff.something do
  with My.Other.Stuff.somethingelse do
    with myyetanother do
    begin
      someproperty := xxx;
      ....
      ....
    end;
It was totally impossible to make sense of anything while debugging!

WITH should be abolished in my view!

I had to make local variables to shorten down the length of the
identifiers and then put the correct variable in front like:
  MS.someproperty := xxx;

Only then was it possible to inspect the values while debugging.

Further: I see every other day in the Embarcadero forum comments by
Remy Lebeau where he strongly advices against using WITH. Only goes to
show that it plagues Delphi as well.

Join the crusade against WITH!!!


--
Bo Berglund
Developer in Sweden

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

Marco van de Voort
In reply to this post by Mark Morgan Lloyd-5
In our previous episode, Mark Morgan Lloyd said:
> > (remember recent discussion about IfThen pseudo-function).
>
> More relevant to your situation, I remember discussion about adding an
> identifier to WITH to use as an explicit shortcut, i.e. something like
>
> with foo= bar do
>    foo.someField := ...

Not relevant since the With code in this case must remain delphi compatible.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12