Re: [fpc-devel] Implicit function specialization precedence
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 return type is st_shortstring you should indeed use SHORTSTRING (it's only constant strings which are a bit more, let's say "dynamic") 3. do an internalerror for st_longstring as those are currently not implemented 4. due to 2. you can move the case of newtype=nil into the if-clause with the arraydef Otherwise, yes, the check for the string type is correct. I didn't know how constant strings we identified until just now so I can correct that. Can we make "(def.typ=arraydef) and (ado_isconststring in tarraydef(def).arrayoptions)" into a function in defutils.pas and call it is_constant_string? That would have been easily visible to me and lead me in the right direction from the start. I also had problems with array literals like [1,2,3] which there is no clear utility function for and prompted me to make is_array_literal() which is private right now (and probably not very correct in design). Moving that to a public space would be sensible also I think. That is because before the introduction of type helpers such functions weren't really needed. Other mechanisms caught such constants, but for both type helpers and these implicit specializations it's hard to do it another way. Regards, Sven ___ 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
> 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 use SHORTSTRING (it's only constant strings which are a bit > more, let's say "dynamic") > 3. do an internalerror for st_longstring as those are currently not > implemented > 4. due to 2. you can move the case of newtype=nil into the if-clause with the > arraydef > > Otherwise, yes, the check for the string type is correct. I didn't know how constant strings we identified until just now so I can correct that. Can we make "(def.typ=arraydef) and (ado_isconststring in tarraydef(def).arrayoptions)" into a function in defutils.pas and call it is_constant_string? That would have been easily visible to me and lead me in the right direction from the start. I also had problems with array literals like [1,2,3] which there is no clear utility function for and prompted me to make is_array_literal() which is private right now (and probably not very correct in design). Moving that to a public space would be sensible also I think. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] String constant truncation - Bug in 3.2.2rc
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
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 get the state of $H+ that would be helpful otherwise
I need to track it down in the debugger. :)
I think I got this part figured out (see function below). I'm going to upload
another patch and a bunch of unit tests on the bug tracker but I'm leaving my
latest ambiguous function call as-is until further notice. it's sneaky like it
is but it follows rules which you can manipulate using casting.
==
function create_unamed_typesym(def:tdef): tsym;
var
newtype: tsym;
begin
newtype:=nil;
if is_stringlike(def) then
begin
if (def.typ=arraydef) and (ado_isconststring in
tarraydef(def).arrayoptions) then
newtype:=nil
else
case tstringdef(def).stringtype of
st_shortstring:
newtype:=nil;
st_longstring,
st_ansistring:
newtype:=search_system_type('ANSISTRING');
st_widestring:
newtype:=search_system_type('WIDESTRING');
st_unicodestring:
newtype:=search_system_type('UNICODESTRING');
end;
{ not better string type was found so chose the default string
type }
if newtype=nil then
begin
if (cs_refcountedstrings in current_settings.localswitches)
then
begin
if m_default_unicodestring in
current_settings.modeswitches then
newtype:=search_system_type('UNICODESTRING')
else
newtype:=search_system_type('ANSISTRING');
end
else
newtype:=search_system_type('SHORTSTRING');
end;
end
else
begin
newtype:=ctypesym.create(def.typename,def);
newtype.owner:=def.owner;
end;
if newtype=nil then
internalerror(2021020904);
result:=newtype;
end;
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 use SHORTSTRING (it's only constant strings which are a
bit more, let's say "dynamic")
3. do an internalerror for st_longstring as those are currently not
implemented
4. due to 2. you can move the case of newtype=nil into the if-clause
with the arraydef
Otherwise, yes, the check for the string type is correct.
Regards,
Sven
___
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
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 appearance at least). Currently the compiler thinks DoThis is better than the non-generic and this may be because it was specialized as DoThis because the parameter of "1" is a ShortInt. What should the rule be here? = procedure DoThis(a: word; b: word); begin end; generic procedure DoThis(a:T; b: word); begin end; begin DoThis(1,1); // DoThis end. In Delphi this takes the non-generic. But I think this comes into a region where things are not clearly documented, thus it's hard to get things "right". In theory one could move the generic check in front of the ordinal check and it should work, but it could get wonky again if you pass e.g. a LongInt into this (Delphi keeps insisting on using the non-generic with a LongInt constant parameter even though if you have two non-generic overloads it will complain that it violates the range of Word and ShortInt... go figure... - with a LongInt variable it will use the generic) Let it be as it is now... this will only result in headaches either way. = generic procedure DoThis(a:T; b: word); begin end; generic procedure DoThis(a: word; b: T); begin end; begin DoThis(1,1); // Can't determine which overloaded function to call end. = This is correct. Delphi behaves the same here (and it would be the same in the non-generic case with T being replaced by ShortInt). Regards, Sven ___ 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
> 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
> otherwise I need to track it down in the debugger. :)
I think I got this part figured out (see function below). I'm going to upload
another patch and a bunch of unit tests on the bug tracker but I'm leaving my
latest ambiguous function call as-is until further notice. it's sneaky like it
is but it follows rules which you can manipulate using casting.
==
function create_unamed_typesym(def:tdef): tsym;
var
newtype: tsym;
begin
newtype:=nil;
if is_stringlike(def) then
begin
if (def.typ=arraydef) and (ado_isconststring in
tarraydef(def).arrayoptions) then
newtype:=nil
else
case tstringdef(def).stringtype of
st_shortstring:
newtype:=nil;
st_longstring,
st_ansistring:
newtype:=search_system_type('ANSISTRING');
st_widestring:
newtype:=search_system_type('WIDESTRING');
st_unicodestring:
newtype:=search_system_type('UNICODESTRING');
end;
{ not better string type was found so chose the default string
type }
if newtype=nil then
begin
if (cs_refcountedstrings in current_settings.localswitches)
then
begin
if m_default_unicodestring in
current_settings.modeswitches then
newtype:=search_system_type('UNICODESTRING')
else
newtype:=search_system_type('ANSISTRING');
end
else
newtype:=search_system_type('SHORTSTRING');
end;
end
else
begin
newtype:=ctypesym.create(def.typename,def);
newtype.owner:=def.owner;
end;
if newtype=nil then
internalerror(2021020904);
result:=newtype;
end;
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
