[fpc-devel] Autogenerated names for internal RecordDefs

Blaise at blaise.ru Blaise at blaise.ru
Sun Dec 1 11:02:57 CET 2019

On 30.11.2019 20:47, Sven Barth via fpc-devel wrote:
> Am 30.11.2019 um 13:27 schrieb Blaise at blaise.ru:
>> { This is a resubmission of https://lists.freepascal.org/pipermail/fpc-devel/2019-August/041915.html }
>> trecorddef.create_global_internal generates internal RecordDef names as
>>     '$InternalRec'+tostr(current_module.deflist.count)
>> However, since such internal RecordDefs are not necessarily registered afterwards (i.e. deflist.count is not going to be bumped), such names do not contain actual DefIDs, and thus are not unique within a module.
>> 1) So, what is the point of that misleading numerical suffix? I propose that it be dropped.
>> 2) My understanding is that a name should never be autogenerated for an internal RecordDef that is going to be registered with a DefID. I propose that this be asserted (two variants are offered).
> I've fixed this now in r43616 by using the correct way to generate a unique ID string.

You are invoking unique_id_str before the inherited constructor sets defid:=defid_not_registered. Before that, defid is 0, so the aforementioned test case shows:
> TRUE    $vmtdef$C
> FALSE   $rttidef$INIT_$U_$$_C
> FALSE   $InternalRec00000000
> FALSE   $InternalRec00000000
> FALSE   $rttidef$RTTI_$U_$$_C
> FALSE   $InternalRec00000000
> FALSE   $InternalRec00000000
> FALSE   $InternalRec00000000
> FALSE   $InternalRec00000000
> FALSE   $InternalRec00000000
At the very least:
which I find hacky.

  The LLVM backend makes use of anonymous record defs and I don't know whether your patch would break that.

Presumably, if such duplicate internal names were breaking LLVM, it would have been noticed already?
Maybe Jonas could weigh in?


More information about the fpc-devel mailing list