[Lazarus] FPReport file names

[Ondrej Pokorny]

On 13.09.2017 21:17, Mattias Gaertner via Lazarus wrote:
>> Everything looks like the compiler uses the same algorithm -> it first
>> resolves a then b then c and so on, it doesn't need to go backwards.
> It's not so simple. See my example for Sven:
> ...
> uses unitdots.unit1, unitdots;
> type
>    TPrgBright = unitdots.tbright;
>    TPrgColor = unitdots.unit1.tcolor; <--
> ...

I don't get it :)
from left to right: is unitdots a namespace? -> yes -> is unit1 a 
subnamespace in unitdots? -> no -> is unit1 a file in unitdots 
namespace? -> yes -> find tcolor type in unitdots.unit1. Why do you need 
to read the identifier backwards?

+ Yes, I have a bug in CodeTools:

program unitdots.main1;
uses unitdots, unitdots.unit1;
type
   TPrgBright = unitdots.tbright;
   TPrgColor = unitdots.unit1.tcolor;
   TStrange = unitdots.main1.tprgcolor;
var k1: longint;
begin
   if unitdots.main1=0 then ; // << compiler error (codetools jump to 
"main1: integer;" in unitdots.pas)
   if unitdots.main1.k1=0 then ; // << OK (codetools don't find k1)
   if unitdots.j1=0 then ;
   if unitdots.unit1.i1=0 then ;
end.

unit unitdots;
interface
type
   tbright = (yes, no);
var
   main1: integer;
   unit1: integer;
   j1: integer;
implementation
end.

unit unitdots.unit1;
interface
type
   tcolor = integer;
var
   i1: tcolor;
implementation
end.

The namespace/unitname takes precedence before an identifier in an 
external unit. But it still looks to me like everything can be resolved 
from left to right - you just need to know the rules. CodeTools don't 
know this rule yet. But once they know it, they will resolve it correctly.

Ondrej