Roger Cigol 131 Posted 6 hours ago It's called the April patch - but it's out now ! https://blogs.embarcadero.com/rad-studio-12-3-april-patch-available/ 1 Share this post Link to post
Uwe Raabe 2134 Posted 5 hours ago 30 minutes ago, Roger Cigol said: It's called the April patch Sounds reasonable: Share this post Link to post
Anders Melander 1980 Posted 5 hours ago @Uwe Raabe Can you confirm that RSS-3102 (the record constrain thing) is fixed for 64-bit also? The last comment on the issue claims it isn't. Share this post Link to post
Lars Fosdal 1850 Posted 4 hours ago It is fixed. It is no longer necessary to remove the record constraint to avoid the non-nullable type error. Edit: Woops - missed that 64-bit thing... do you mean the 64-bit target, or the 64-bit compiler? Share this post Link to post
Anders Melander 1980 Posted 3 hours ago 40 minutes ago, Lars Fosdal said: do you mean the 64-bit target, or the 64-bit compiler? I think the comment refers to the 64-bit compiler, so that's what I'm asking about. I assume the 64-bit target is okay but since Embarcadero doesn't really provide any useful info (in any of the issues) it's just an assumption. Share this post Link to post
Lars Fosdal 1850 Posted 2 hours ago @Anders Melander I just tried my example code which failed before the April patch in the 64-bit IDE, targeting 64-bit Windows. It no longer stops compiling. program NonNullableConstraint; {$APPTYPE CONSOLE} {$R *.res} uses System.SysUtils; type TMyClass = class function Select<T:Record>(const selector: string):TArray<T>; end; TNotifcationRow = record const Query = 'SELECT * FROM v_server_notifications'; public Id: Integer; Name: String; Data: String; ByWho: String; CreatedWhen: TDateTime; function DataAsId: Integer; end; TServerNotificationArray = TArray<TNotifcationRow>; { TMyClass } function TMyClass.Select<T>(const selector: string): TArray<T>; begin end; procedure Test; var MyClass: TMyClass; Res: TServerNotificationArray; begin MyClass := TMyClass.Create; Res := MyClass.Select<TNotifcationRow>('foo'); // <- E2512 Type parameter 'T' must be a non-nullable value type end; { TNotifcationRow } function TNotifcationRow.DataAsId: Integer; begin Result := 0; end; begin try Test; except on E: Exception do Writeln(E.ClassName, ': ', E.Message); end; end. 1 Share this post Link to post
Uwe Raabe 2134 Posted 2 hours ago 15 minutes ago, Lars Fosdal said: I just tried my example code which failed before the April patch in the 64-bit IDE, targeting 64-bit Windows. Try with external MSBuild in the project options and select x64 as preferred architecture. Key is to use the 64-bit compiler versions from the bin64 folder. The target platform is almost irrelevant. Only bcc64x got an update with the April patch. 1 Share this post Link to post
Lars Fosdal 1850 Posted 2 hours ago 24 minutes ago, Uwe Raabe said: Try with external MSBuild in the project options and select x64 as preferred architecture. Key is to use the 64-bit compiler versions from the bin64 folder. The target platform is almost irrelevant. Only bcc64x got an update with the April patch. Yeah, THAT surfaced the dreaded error [dcc64 Error] NonNullableConstraint.dpr(41): Type parameter 'T' must be a non-nullable value type Half-baked patches are no fun. Edit - Also noticed that the Error ID is lost when using MSBuild. Share this post Link to post
Uwe Raabe 2134 Posted 1 hour ago 10 minutes ago, Lars Fosdal said: Half-baked patches are no fun. I wonder if beta testing for the patches would help here. Share this post Link to post
dummzeuch 1631 Posted 1 hour ago 2 minutes ago, Uwe Raabe said: I wonder if beta testing for the patches would help here. Aren't we doing that right now? 1 Share this post Link to post
Anders Melander 1980 Posted 1 hour ago 40 minutes ago, Lars Fosdal said: Yeah, THAT surfaced the dreaded error Thanks. 28 minutes ago, Uwe Raabe said: I wonder if beta testing for the patches would help here. It would but something like this shouldn't have passed internal QA in the first place. A compiler engineer would have known that the first thing you do when solving something like this is to write a regression test to first reproduce the problem and later verify that it is fixed. Maybe it would be a good idea if they hired some - compiler engineers, that is. Share this post Link to post
Uwe Raabe 2134 Posted 1 hour ago 47 minutes ago, dummzeuch said: Aren't we doing that right now? Unfortunately not for every patch. Share this post Link to post