You do not specify a {$mode} in your project or units, which means they default to mode fpc (not objfpc, or delphi), which is probably not what you want.Howard, is this really true? In the Lazarus project options ("Compiler options" > "Parsing") there's a setting for "Syntax mode (-M, {$MODE})". Isn't this the mode used when a mode is not specified for a unit?
I don't have much experience with generics, but is your declaration of generic classes correct? You declareAccording to http://wiki.freepascal.org/Generics#Custom_Generic_Classes, shouldn't this be like this?
Tested and followed what jakubklos said. It is 100% reproducible on Lazarus 1.8.0 FPC 3.04 64-bit Gtk2 Linux.
Using compile (Ctrl+F9) will get a compile-time error but no error if I use Build (Shift+F9).
No. It is just the unit concept that causes this and that is a feature. People coming from other languages are unfamiliar with this behavior, but it allows for (much!) faster compiles. Touched units are recompiled in any case, but related code in un-touched units may have to be recompiled as well. Usually it is caused by bad design but that is not always the case.Tested and followed what jakubklos said. It is 100% reproducible on Lazarus 1.8.0 FPC 3.04 64-bit Gtk2 Linux.
Using compile (Ctrl+F9) will get a compile-time error but no error if I use Build (Shift+F9).
My previous post was based on "build" compilation, now I tested "compile" (Ctrl+F9) mode (win32, FPC 3.4, Lazarus 1.8, code parsing mode -MDelphi) and problem signalled by TS appeared for me too. The problem may be in FPC(/Lazarus) - changed source (even when the change is reverted) is badly treated by FPC in "compile" and "quick compile" compilation (file timestamps not properly maintaned?).
WooBean
problem signalled by TS appeared for me toomeans
EAccessViolation: Access violation
$0044EFB6
$004E7F50
$004F8FB4
...
that is a bug in FPC which is "unfixable", please read above.You do not specify a {$mode} in your project or units, which means they default to mode fpc (not objfpc, or delphi), which is probably not what you want.Howard, is this really true? In the Lazarus project options ("Compiler options" > "Parsing") there's a setting for "Syntax mode (-M, {$MODE})". Isn't this the mode used when a mode is not specified for a unit?
The issue does not occur on Linux with FPC 2.4.6Crazy Monday?
We could stick with 2.4.6 but the support for unicode filenames on Windows is crucial for us.
Looks like we will be stuck with old Delphi then :(. I was so hoping to get rid of it and use Lazarus
Yes, that is true. But if you have hundreds of units it takes a few minutes for the build to finish. We wanted to migrate from Delphi because of the IDE horror (instability, slowness etc.) I have been using Lazarus for more than 2 years on Linux and I am happy with it. Now I wanted all developers to work in Lazarus but if there are issues like this they will not like me very much ;)Just guessing why you are in trouble I found in the Net some comments on huge time (minutes) compilation in Delphi (10.2 actually) when using generics. It seems to me, that generics approache coding touches (in FPC too) so much of existing libraries ("hiddenly" used by a compiler) and needs checking (and replacing something) almost everywhere what forces a user to wait, wait .... . And it is your case, probably.
Would it make a difference if I post this isse directly to the FPC bug tracker?If it is reproducible I definitely would submit a bug report.
I have changed the whole project to ObjFPC mode and it does not help. The behavior is the same.That's what you should NOT have done. Or you should do the opposite! Mode Delphi! when converting manually.
Almost every 2nd unit suffers from this issue btw. So you can imagine how long it took me to re-build and re-build and finish porting the project. It took hours because of this issue.
Would it make a difference if I post this isse directly to the FPC bug tracker?
Thank you
Because the fatal error was correct and your code was a mess....My expectation of the compiler is to report syntax and other code errors to the user, not puke all over itself when confronted with an invalid construct. So regardless of whatever user code errors there may be in this case, the compilers should still not raise an exception - thus in my opinion there is a compiler bug.
That's exactly what it - the compiler - did.... Try all the code yourself and you see why. He made a mess. It is not a compiler CRASH it is a fatal error because of the FOOD and it terminates gracefully with a nice error message.... Now... How Trump-like are you????