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

[Blaise at blaise.ru]

On 03.08.2019 16:54, Blaise at 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.

-- 
βþ
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: create_global_internal-3.patch
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20190813/3c20247d/attachment.ksh>