[fpc-devel] Implicit function specialization precedence

[Sven Barth]

Am 08.04.2021 um 19:28 schrieb Ryan Joseph via fpc-devel:
>
>> On Apr 7, 2021, at 1:56 PM, Ryan Joseph <genericptr at gmail.com> 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