Am 01.12.2019 um 11:02 schrieb bla...@blaise.ru:
On 30.11.2019 20:47, Sven Barth via fpc-devel wrote:
Am 30.11.2019 um 13:27 schrieb bla...@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?


Fixed in r43624 and r43625. I've decided to keep the unique names, because they are useful when debugging. More useful then say the Self value.

Regards,
Sven
_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply via email to