Re: [fpc-devel] Scoped VMTDefs \ autogenerated names for internal RecordDefs

2019-08-13 Thread Blaise

On 03.08.2019 16:54, bla...@blaise.ru wrote:

trecorddef.create_global_internal


Currently, autogenerated internal names are composed as
'$InternalRec'+tostr(current_module.deflist.count)
IMO, this is misleading: it appears as if such names 1) would be unique within 
a module, and 2) would encode the respective DefIDs; in actuality, neither 
happens (since such internal RecordDefs are not necessarily registered).

This can be demonstrated by logging
writeln(current_module.in_interface, #9, objrealname^)
@ create_global_internal.
For a simple unit
---8<---
unit U;
interface
type C = class end;
implementation
end.
---8<---
it shows

TRUE$vmtdef$C
FALSE   $rttidef$INIT_$U_$$_C
FALSE   $InternalRec16
FALSE   $InternalRec16
FALSE   $rttidef$RTTI_$U_$$_C
FALSE   $InternalRec16
FALSE   $InternalRec16
FALSE   $InternalRec16
FALSE   $InternalRec16
FALSE   $InternalRec16


So, what is the point?
Initially, I wanted to use deflist.count from the "where" symbol table (i.e. 
current_module.localsymtable or .globalsymtable; or a specified table -- for my upcoming 
Scoped VMTDefs patch) instead. But, wouldn't it be better to drop that misleading suffix 
altogether?

My understanding is that a name should never be autogenerated for an internal 
RecordDef that is going to be registered with a DefID, thus, we can even 
ASSERT( not current_module.in_interface ) in that case.

A draft patch is attached. The assertion comes in two flavours -- decide which 
(if any) is appropriate.

--
βþ
# HG changeset patch
# User Blaise.ru
# Date 1565724859 -10800
#  Âò àâã 13 22:34:19 2019 +0300
# Node ID 62f89d03bc699f0968e12a44c539e4c4866c8f81
# Parent  f865fbcda516f75d455c963c46e0efa00d009c5c
= trecorddef.create_global_internal: non-misleading autogenerated names

diff -r f865fbcda516 -r 62f89d03bc69 symdef.pas
--- a/symdef.pasÂò àâã 13 00:10:03 2019 +0300
+++ b/symdef.pasÂò àâã 13 22:34:19 2019 +0300
@@ -4784,8 +4784,8 @@
 
 
 constructor trecorddef.create_global_internal(const n: string; 
packrecords, recordalignmin: shortint);
+  const internaltypeName: string = '$InternalRec';
   var
-name : string;
 pname : pshortstring;
 oldsymtablestack: tsymtablestack;
 where : tsymtable;
@@ -4796,8 +4796,9 @@
   pname:=@n
 else
   begin
-name:='$InternalRec'+tostr(current_module.deflist.count);
-pname:=@name;
+if current_module.in_interface then
+  internalerror(2019081301); // do not register a nameless def
+pname:=@internaltypeName;
   end;
 oldsymtablestack:=symtablestack;
 { do not simply push/pop current_module.localsymtable, because
@@ -4821,7 +4822,10 @@
   typed constant data) }
 ts.increfcount;
 where.insert(ts);
-  end;
+  end
+else
+  if defid<>defid_not_registered then
+internalerror(2019081301); // we registered a nameless def
 symtablestack:=oldsymtablestack;
 { don't create RTTI for internal types, these are not exported }
 defstates:=defstates+[ds_rtti_table_written,ds_init_table_written];
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel


Re: [fpc-devel] Scoped VMTDefs

2019-08-11 Thread Ryan Joseph
Very eager for closures. Btw, what’s the status Blaise? I didn’t hear back 
since last month or so.

Regards,
Ryan Joseph

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


Re: [fpc-devel] Scoped VMTDefs

2019-08-11 Thread Sven Barth via fpc-devel

Am 03.08.2019 um 15:54 schrieb bla...@blaise.ru:
Before the main course, I offer the attached refactorings for 
trecorddef.create_global_internal:

1) streamline insertions into the symtable;


Applied in r42652


2) avoid shadow-copying of the parameter "n", which is now const


Applied in r42653

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