Re: [fpc-devel] Implicit function specialization precedence

2021-04-08 Thread Sven Barth via fpc-devel
Am 09.04.2021 um 04:20 schrieb Ryan Joseph via fpc-devel: On Apr 8, 2021, at 3:53 PM, Sven Barth wrote: 1. you should not blindly assume that the def is a stringdef if it's not an arraydef; at least use an internalerror to protect against problems here 2. if it's really a stringdef and the

Re: [fpc-devel] Implicit function specialization precedence

2021-04-08 Thread Ryan Joseph via fpc-devel
> On Apr 8, 2021, at 3:53 PM, Sven Barth wrote: > > 1. you should not blindly assume that the def is a stringdef if it's not an > arraydef; at least use an internalerror to protect against problems here > 2. if it's really a stringdef and the return type is st_shortstring you > should indeed

[fpc-devel] String constant truncation - Bug in 3.2.2rc

2021-04-08 Thread Martin Frb via fpc-devel
Just for info: https://forum.lazarus.freepascal.org/index.php?topic=54050.new ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Implicit function specialization precedence

2021-04-08 Thread Sven Barth via fpc-devel
Am 08.04.2021 um 19:28 schrieb Ryan Joseph via fpc-devel: On Apr 7, 2021, at 1:56 PM, Ryan Joseph wrote: Ok, so with $H+ constant strings will be specialized as AnsiStrings. And there is another unicode string mode I should do a similar thing with? Also if you happen to know where I can

Re: [fpc-devel] Implicit function specialization precedence

2021-04-08 Thread Sven Barth via fpc-devel
Am 07.04.2021 um 23:21 schrieb Ryan Joseph via fpc-devel: With the requested changes I believe some precedence rules have changed. These both should be "Can't determine which overloaded function to call" errors or the non-generic should take precedence because the functions are ambiguous (by

Re: [fpc-devel] Implicit function specialization precedence

2021-04-08 Thread Ryan Joseph via fpc-devel
> On Apr 7, 2021, at 1:56 PM, Ryan Joseph wrote: > > Ok, so with $H+ constant strings will be specialized as AnsiStrings. And > there is another unicode string mode I should do a similar thing with? Also > if you happen to know where I can get the state of $H+ that would be helpful >