Okay, okay. Not too harsh, please.
I feel I don't yet know enough about defs and generics to properly fix this bug, only that the defs used aren't getting written out as debug information because of the df_generic flag being present.
In the attached .s file, you can search for the reference to .La17 on line 600 that refers to a generic def, related to the line "R.GetArr<single>;" in the source file.
(tw38827.lpr)
program tw38827;
{$mode delphi}
uses tw38827_u;
var R: TRec;
begin
R.GetArr<single>;
end.
(tw38827_u.pas)
unit tw38827_u;
{$mode delphi}
interface
type
TRec = record
C: TArray<single>;
function GetArr<T>: TArray<T>; inline;
end;
implementation
function TRec.GetArr<T>: TArray<T>;
begin
result := nil;
case GetTypeKind(T) of
tkFloat:
if SizeOf(T) = SizeOf(Single) then result := C;
end;
end;
end.
Gareth aka. Kit
Sven Barth wrote 25 lines
Am 03.07.2021 um 15:01 schrieb J. Gareth Moreton via fpc-devel:
> Hi everyone,
>
> I'm trying to fix i38827, and am trying a few things. One thing I've
> noticed is that some specializations have both the df_generic and
> df_specialization flags set, and the def missing from the debug
> information that raises the linker error is one such def. Manually
> removing the df_generic fixes the problem (since the presence of the
> flag stops it from being written to the debug information), but is
> there a situation where a def can legitimately have both flags set?
>
> To guess, I would say if a generic has multiple parameters and not
> all of them are specialized, then that makes a def that's both, but
> then a fully specialized generic type shouldn't have the generic flag
> any more, right?
First of you *do not* modify defs when writing debug information.
Period. (except for fields that are *only* related to debug information)
Second df_generic is set for any def *inside* a generic. The TArray<T>
is a specialization inside a generic thus it will have both flags set.
Regards,
Sven
