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
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 

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?

fpc-devel maillist  -  fpc-devel@lists.freepascal.org

Reply via email to