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?

--
βþ
_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Reply via email to