[fpc-devel] test/cg/variants/tnofalvarol.pp

[Jonas Maebe]

On 03/05/2019 17:48, J. Gareth Moreton wrote:
> So I was doing some refactoring work, and ran the test suites to see if 
> nothing broke.  It turned out that I got a single failure in 
> test/cg/variants/tnofalvarol.pp - seems a little odd because my changes 
> weren't meant to change the output of binary files in any way.  But 
> looking at the test in question, all I get is a wall of $include 
> definitions.  Running it in Lazarus isn't too helpful either because the 
> stack trace doesn't reveal where the erroneous line is, only that seven 
> levels down, an error occurs in "destructor tdynarrayiter.done;" in the 
> variants unit, but doesn't know which line exactly - exception 
> EVariantError with message: "Invalid variant type cast".

"destructor tdynarrayiter.done;" is part of 
packages/rtl-objpas/src/inc/variants.pp. You don't get more information 
because all units from the packages directory are compiled with 
optimizations and without debug information by default. You will have to 
compile that unit with debug information (you can add OPT="-O- -gw" to 
the make command when building all of FPC to get everything built 
without optimizations and with debug information).

> I suppose what I'm trying to get at is that this test is not very 
> self-contained and is very hard to debug if it happens to fail, and I 
> would consider rewriting or replacing it.

The files it includes have been automatically generated, automatically 
tested against Kylix, and then
a) if the program compiled with Kylix, it was run to see which overload 
Kylix picked and whether it generated an exception, and a "halt(1)" was 
(also automatically) placed in the other paths. All successfully 
executing tests are included in tnofalvarol.pp to make the test go 
faster (compiling and running one program with 100 include files is much 
faster than compiling 100 separate files)
b) if the program did not compile with Kylix, it was kept as a separate 
program (since if you include two failing programs in a single program 
and it fails to compile, we can't test whether both errors were detected).

You can still compile the individual include files of the test as 
separate programs to test and debug them separately. Once you compile 
the variants unit with debug information, you should be able to easily 
see which individual test is crashing based on the backtrace.


Jonas