[fpc-devel] Local classes and interfaces

[Sven Barth]

Am 21.12.2020 um 16:22 schrieb Blaise--- via fpc-devel:
> On 19.12.2020 16:51, Sven Barth wrote:
>> Considering that it's only intended for internal use, yes I'm aboard 
>> with that.
>
> Here is the first change: 
> http://hg.blaise.ru/public/fpc/rev/7c78bfdaed9a (attached).
>
> Strictly speaking, some local classes and interfaces can be compiled 
> without that -- the ICE 200204175 only occurs when they have their own 
> entities such as nested classes (not used for Closures) and 
> non-abstract methods:
> -------8<-------
> function Foo: TClass;
>     type Local = class
>         type Nested = class end;
>         procedure Method;
>     end;
>     procedure Local.Method;
>     begin
>     end;
> begin
>     result := Local
> end;
>
> begin
>     Foo
> end.
> -------8<-------
>
> To observe the effect, one could temporarily use the second attached 
> patch to force FPC to compile the above test case. The following 
> internal names are generated for it:
> VMT_$P$PROGRAM$_$FOO_$$_LOCAL // no change
> VMT_$P$PROGRAM$_$FOO_$LOCAL_$__$$_NESTED // was: ICE
> P$PROGRAM$_$FOO_$LOCAL_$__$$_METHOD // was: ICE
> Please check that such names are in line with the intended format.

The format should indeed be okay. Applied in r47834.

>
>> I'd say in this case the bug is that the declaration of those two 
>> Cls<> types is allowed.
>
> Looking at the excerpt from object_dec:
>>         { objects and class types can't be declared local }
>>         if not(symtablestack.top.symtabletype in 
>> [globalsymtable,staticsymtable,objectsymtable,recordsymtable]) and
>>            not assigned(genericlist) then
>>           Message(parser_e_no_local_objects);
> "assigned(genericlist)" seems intentional. Maybe, it misses a check 
> for generic instantiation

That might probably be a left over from old times when genericlist was a 
rather reliable check.

> ; however:
>
>> If I remember correctly *specializations* are already placed in the 
>> more nested scope if they use local types.
>
> Judging solely by the internal names, that is not what happens.
>
>> or at least that was the plan
>
> If you were to implement that, you would encounter the same ICE.

Could be that I only had intended to do that then, but hadn't yet found 
the time to indeed do so...

Regards,
Sven