[fpc-devel] Autogenerated names for internal RecordDefs

[Blaise at blaise.ru]

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:
	defid:=defid_not_registered;
	name:='$InternalRec'+unique_id_str;
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?

-- 
βþ