Issue http://bugs.freepascal.org/view.php?id=22365 was about the compilation error
when the TAChart code is compiled by FPC trunk.

I did not notice the issue in time, because bug tracker is unusably slow, so I use Google Alerts to track bugs. This usually works, but sometimes causes a delay of a few days before Google notification. Sorry for that.

The issue is resolved, so it is impossible to discuss -- this is why I start discussion here.
I Cc'd original reporter -- hopefully he does not mind.

I am grateful for Mattias for stepping up and resolving the issue, but I'd appreciate some discussion for such controversial changes.

Regarding the specifics of the problem -- FPC trunk (suddently?) stopped compiling
TAChart source. Affected code did not change recently, so this is either a FPC regression
or some general issue like out-of-date object files, wrong installation paths leading to version conflicts etc. So I have a few questions/suggestions:
1) Can anybody (Mattias?) reproduce this?
2) Why did this suddently happened? Why do not all other trunk users complain?
3) Can this be isolated to a smaller testcase and reported as an FPC bug?
4) Alternatively, is this an intentional backwards-incompatible change in FPC? Should it be documented as such?
5) If the bug is too subtle/hard to fix, at least the workaround in TAChart code should be clearly marked as such -- there are a few examples in TAChart, search for 'workaround'

yes

2) Why did this suddently happened? Why do not all other trunk users complain?

I guess tachart uses a seldom combination of generics, implementation uses and operators.

3) Can this be isolated to a smaller testcase and reported as an FPC bug?

Maybe these hints can help to create a smaller example:

TGenericChartMarks is a generic, which uses in its implementation some identifiers defined by the uses section of the implementation section.

operator +(const A: TPoint; B: TSize): TPoint of unit TAGeometry
and
TCustomChartSource of unit TACustomSource

Mattias

Alexander Klenin wrote

So I have a few questions/suggestions: 1) Can anybody (Mattias?) reproduce this?

Yes, had the same problem, 32 bit and IIRC also 64 bit FPC on Win x64.

As mentioned in the BT, John Repucci (IPGuy on the forum) had the same problem on x86, Windows; forum posts:
http://lazarus.freepascal.org/index.php/topic,15919.msg96174.html#msg96174

2) Why did this suddently happened? Why do not all other trunk users complain?

To be honest, I don't report every build issue with Lazarus and FPC trunk because jshand2010 seems to do so quite diligently...

I don't know whether any automated system exists that shows Lazarus build failures for stable platforms and injects them into the bugtracker and/or shows a publically available status page... which might help these kind of things.

FPC does have/used to have at least compiler (but not e.g. database) test suite run output on a web page but I can't find the link... remember a post in fpc-dev a while back (2010 perhaps?) mentioning that. Don't know if build status is also available.

"Mattias Gaertner" wrote

> 2) Why did this suddently happened? Why do not all other trunk users

complain?

I guess tachart uses a seldom combination of generics, implementation uses and operators.

The lovely topic "generics" *sigh*

> 3) Can this be isolated to a smaller testcase and reported as an FPC

bug?

Outch! That would explain it... As a general rule: don't use implementation only stuff inside generics that are made available in the interface section. The only exception to this might be untyped constants in Delphi mode, because Delphi allows them as well (there is a bug report from Marco about this)

operator +(const A: TPoint; B: TSize): TPoint of unit TAGeometry and TCustomChartSource of unit TACustomSource

Regards,
Sven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120706/08deca98/attachment.html>