Lazarus

Free Pascal => General => Topic started by: 440bx on April 12, 2021, 08:40:56 am

Title: No warning from FPC with ambiguous overload
Post by: 440bx on April 12, 2021, 08:40:56 am
Hello,

FPC determines which overloaded function/procedure to call by matching the parameters in the call to the parameters in the definitions, which is fine but, there are times when that isn't enough information to choose the correct overload.

Consider this example:
Code: Pascal  [Select][+][-]
  1. program AmbiguousOverload;
  2.  
  3. uses
  4.   Windows
  5.   ;
  6.  
  7. const
  8.   ntdll    = 'ntdll';
  9.   kernel32 = 'kernel32';
  10.  
  11.  
  12. function swprintf({ _out_ } OutWideBuffer    : pwidechar;
  13.                   { _in_  } InFormatString   : pwidechar;
  14.                   { _in_  } InWidechars      : pwidechar)
  15.          : integer; cdecl; external ntdll;                          { CDECL !!}
  16.  
  17. function swprintf({ _out_ } OutWideBuffer    : pwidechar;
  18.                   { _in_  } InFormatString   : pwidechar;
  19.                   { _in_  } InAnsiChars      : pchar)
  20.          : integer; cdecl external ntdll;                           { CDECL !!}
  21.  
  22.  
  23. var
  24.   WideBuf : packed array[0..511] of widechar;
  25.  
  26. begin
  27.   writeln;
  28.  
  29.   { the compiler should emit a warning stating that there isn't enough        }
  30.   { information to decide which overload to pick.                             }
  31.  
  32.   swprintf(WideBuf,
  33.            '%s',
  34.            'Hello character world!');  { compiler picks pchar overload        }
  35.  
  36.   writeln(unicodestring(WideBuf));
  37.  
  38.  
  39.   { now the same but explicitly resolving the ambiguity                       }
  40.  
  41.   swprintf(WideBuf,
  42.            '%s',
  43.            pwidechar('Hello character world!'));  { picks widechar overload   }
  44.  
  45.   writeln(unicodestring(WideBuf));
  46.  
  47.  
  48.   writeln;
  49.   writeln('press ENTER/RETURN to end this program');
  50.   readln;
  51. end.            
One of the swprintf overloads specifies a pchar parameter and the other a widechar parameter.

When the compiler encounters the call at line 34 (highlighted), there isn't enough information in that statement for the compiler to determine that it should choose the widechar overload (swprintf requires a widechar but that fact isn't part of the overload resolution.) Instead it simply _assumes_ the characters should be single byte characters and picks the pchar overload resulting in output which is not quite as desired.

The compiler should probably emit at least a warning when it encounters a situation like the one above to inform the user that the "chosen overload" is simply a guess.  The other potential problem of making that guess is that the swprintf function and likely all widechar functions expect the string to be terminated with two null widechars and a pchar string is only guaranteed to provide a single null byte opening the door to buffer overruns.

But, the above situation in a GUI program that uses TextOutW instead of writeln shows some really ornate and quite artistic Asian characters. :)  (gotta always look for the silver lining)
Title: Re: No warning from FPC with ambiguous overload
Post by: PascalDragon on April 12, 2021, 09:01:25 am
There is no guess. As long as a string constant does not contain any characters that require a WideChar (and the UnicodeStrings modeswitch is not enabled) then a PAnsiChar is preferred to a PWideChar.
Title: Re: No warning from FPC with ambiguous overload
Post by: 440bx on April 12, 2021, 09:11:09 am
There is no guess. As long as a string constant does not contain any characters that require a WideChar (and the UnicodeStrings modeswitch is not enabled) then a PAnsiChar is preferred to a PWideChar.
That's fine but, the compiler should let the programmer know by a warning or at least a hint that PAnsiChar is preferred over PWideChar because there are situations like the one above where that "preference" leads to undesirable results.

That preference is just a built-in guess in the compiler.
Title: Re: No warning from FPC with ambiguous overload
Post by: ccrause on April 12, 2021, 09:29:10 am
Do you have documentation for the NTdll version of swprintf which mentions that an ansichar pointer parameter is supported?  The Visual Studio 2019 documentation (https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/sprintf-sprintf-l-swprintf-swprintf-l-swprintf-l?view=msvc-160) mentions this:
Quote
swprintf is a wide-character version of sprintf; the pointer arguments to swprintf are wide-character strings.
To me it seems as if an overload for an ansichar pointer version is not provided (at least in the standard C runtime).
Title: Re: No warning from FPC with ambiguous overload
Post by: PascalDragon on April 12, 2021, 09:33:01 am
There is no guess. As long as a string constant does not contain any characters that require a WideChar (and the UnicodeStrings modeswitch is not enabled) then a PAnsiChar is preferred to a PWideChar.
That's fine but, the compiler should let the programmer know by a warning or at least a hint that PAnsiChar is preferred over PWideChar because there are situations like the one above where that "preference" leads to undesirable results.

That preference is just a built-in guess in the compiler.

There will not be a warning for this.
Title: Re: No warning from FPC with ambiguous overload
Post by: 440bx on April 12, 2021, 09:39:01 am
Do you have documentation for the NTdll version of swprintf which mentions that an ansichar pointer parameter is supported?  The Visual Studio 2019 documentation (https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/sprintf-sprintf-l-swprintf-swprintf-l-swprintf-l?view=msvc-160) mentions this:
Quote
swprintf is a wide-character version of sprintf; the pointer arguments to swprintf are wide-character strings.
To me it seems as if an overload for an ansichar pointer version is not provided (at least in the standard C runtime).
Yes, I do have documentation for that.  Specifically, sprintf allows a "%S" (capital S) to indicate that the parameter is a null terminated sequence of widechar(s).  Likewise, swprintf allows a "%S" to indicate that the parameter is a null terminated ansi (single byte) sequence of characters.

IOW, both sprintf and swprintf can take either wide character or single character parameters, it only depends on the format specifier.

Also, that capability _is_ present in the standard C runtime library and it is documented (in the supported format specifiers.)

There will not be a warning for this.
That's very unfortunate because there definitely should be one.  The code is absolutely correct yet, it doesn't work because the compiler made a decision behind the programmer's back and, you're saying the compiler shouldn't inform the user of that fact.  When the compiler makes decisions behind the programmer's back, the least it should do is to let the programmer know.
Title: Re: No warning from FPC with ambiguous overload
Post by: MarkMLl on April 12, 2021, 10:09:06 am
There will not be a warning for this.
That's very unfortunate because there definitely should be one.  The code is absolutely correct yet, it doesn't work because the compiler made a decision behind the programmer's back and, you're saying the compiler shouldn't inform the user of that fact.  When the compiler makes decisions behind the programmer's back, the least it should do is to let the programmer know.

This is not a democracy and this will not be going to a vote, but I second your expression of discontent.

C++'s entire system of automatic type conversion etc. badly needs tightening up.

MarkMLl
Title: Re: No warning from FPC with ambiguous overload
Post by: ccrause on April 12, 2021, 10:17:17 am
Do you have documentation for the NTdll version of swprintf which mentions that an ansichar pointer parameter is supported?  The Visual Studio 2019 documentation (https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/sprintf-sprintf-l-swprintf-swprintf-l-swprintf-l?view=msvc-160) mentions this:
Quote
swprintf is a wide-character version of sprintf; the pointer arguments to swprintf are wide-character strings.
To me it seems as if an overload for an ansichar pointer version is not provided (at least in the standard C runtime).
Yes, I do have documentation for that.  Specifically, sprintf allows a "%S" (capital S) to indicate that the parameter is a null terminated sequence of widechar(s).  Likewise, swprintf allows a "%S" to indicate that the parameter is a null terminated ansi (single byte) sequence of characters.

IOW, both sprintf and swprintf can take either wide character or single character parameters, it only depends on the format specifier.

Also, that capability _is_ present in the standard C runtime library and it is documented (in the supported format specifiers.)
Thanks for clarifying what is available.  This means that there isn't an overloaded function in the library/dll, the type of the string pointer is interpreted according to the format string?

To get back the the compiler choosing between ansistring and widestring: the literal string can be converted (in this case) to either ansi or wide string.  With no further information given to the compiler, why do you think it is wrong to pick the most compact and exact representation of the string literal and choose the provided overload that matches this?

Quote
There will not be a warning for this.
That's very unfortunate because there definitely should be one.  The code is absolutely correct yet, it doesn't work because the compiler made a decision behind the programmer's back and, you're saying the compiler shouldn't inform the user of that fact.  When the compiler makes decisions behind the programmer's back, the least it should do is to let the programmer know.
There are potentially numerous implicit type conversions applied by the compiler, if the compiler should mention each one it would be more than useless as it will swamp the compiler messages and hide the really important messages.

Edit: fixed quoting
Title: Re: No warning from FPC with ambiguous overload
Post by: MarkMLl on April 12, 2021, 10:36:37 am
There are potentially numerous implicit type conversions applied by the compiler, if the compiler should mention each one it would be more than useless as it will swamp the compiler messages and hide the really important messages.

Except that the one being considered here is the specific case of there being an arbitrary and silent selection of a user-defined function. This is not a simple assignment issue.

OTOH we were told a few days ago that the order user-defined functions were checked was consistent, even if it was implementation-defined. So once one is aware of this being a potential problem one can have assertions testing the compiler's behaviour in a unit's initialisation.

https://forum.lazarus.freepascal.org/index.php/topic,54027.msg400893.html#msg400893

I've been using Quartus-II software for FPGAs a bit over the last few days, and was impressed by the way that its output messages are sorted into separate tabbed pages: an overall one, another for suppressed messages and so on.

MarkMLl
Title: Re: No warning from FPC with ambiguous overload
Post by: 440bx on April 12, 2021, 10:52:02 am

MarkMLI posted while I was writing this, he is exactly right, "silent selection" is not a good thing.


Thanks for clarifying what is available.  This means that there isn't an overloaded function in the library/dll, the type of the string pointer is interpreted according to the format string?
You're welcome and, that is correct.  There cannot be an overload because the "..." is generic, it has no associated type.  Their type will be determined/interpreted according to the format specifier(s) (which better be correct or else... )

With no further information given to the compiler, why do you think it is wrong to pick the most compact and exact representation of the string literal and choose the provided overload that matches this?
because the case is ambiguous and whatever decision the compiler makes, may or may not be right.  In those cases, the least the compiler should do is to let the programmer know that it made a decision which is _not_ guaranteed to be correct.  It is the fact that the decision is potentially incorrect that justifies emitting a warning.

There are potentially numerous implicit type conversions applied by the compiler, if the compiler should mention each one it would be more than useless as it will swamp the compiler messages and hide the really important messages.
But normally those conversions are deterministic.  IOW, the compiler can figure out what is unambiguously correct.  Whenever the compiler doesn't know the answer it's supposed to rely on the programmer to determine what is correct.  Compiler "preferences" cannot be used to justify a choice that may or may not be correct.  That's the programmer's job but, the programmer relies on the compiler to tell him/her where it made a decision not based on correctness but on "preference". 

As far as swamps of compiler messages that hide really important messages, anyone who programs directly to the Windows API (I do) gets a swamp of utterly useless messages because FPC decided that "var" parameters should be initialized.  Somewhere in the ballpark of 3/5 of Windows API calls generates one of those useless messages that get in the way of the important ones.  The only workaround, you have to write your own API definitions, otherwise you get swamped.

The bottom line is, loads of completely useless messages but, the one message the programmer _really_ needs to have telling him/her that the compiler made the wrong choice, that one, you don't get.  It's like giving free shampoo to totally bald people and withholding it from long-hair hippies. 
Title: Re: No warning from FPC with ambiguous overload
Post by: WooBean on April 12, 2021, 11:14:47 am
Hi,

I think that situation as is (in the example) doesn't need any action from FPC team.
When editing the source a programer  hit key "(" after "swprintf" and codetools code completion displays available overloaded versions.  This is enough to use the needed one.
Below a small change to code used by TS to illustrate it (forcing pWideChar variant of the overloaded function) .

Code: Pascal  [Select][+][-]
  1. program project3;
  2.  
  3. uses
  4.   Windows
  5.   ;
  6.  
  7. const
  8.   ntdll    = 'ntdll';
  9.   kernel32 = 'kernel32';
  10.  
  11.  
  12. function swprintf({ _out_ } OutWideBuffer    : pwidechar;
  13.                   { _in_  } InFormatString   : pwidechar;
  14.                   { _in_  } InWidechars      : pwidechar)
  15.          : integer; cdecl; external ntdll;                          { CDECL !!}
  16.  
  17. function swprintf({ _out_ } OutWideBuffer    : pwidechar;
  18.                   { _in_  } InFormatString   : pwidechar;
  19.                   { _in_  } InAnsiChars      : pchar)
  20.          : integer; cdecl external ntdll;                           { CDECL !!}
  21.  
  22.  
  23. var
  24.   WideBuf :  packed array[0..511] of widechar;
  25.   WideChars: wideString;
  26. begin
  27.   writeln;
  28.  
  29.   { the compiler should emit a warning stating that there isn't enough        }
  30.   { information to decide which overload to pick.                             }
  31.   WideChars:='Hello unicode world!';
  32.   swprintf(WideBuf,
  33.            '%s',
  34.            pWideChar(@WideChars[1]));   //my 2 cents /WB
  35.            //'Hello character world!');  { compiler picks pchar overload        }
  36.  
  37.   writeln(unicodestring(WideBuf));
  38.  
  39.   { now the same but explicitly resolving the ambiguity                       }
  40.  
  41.   swprintf(WideBuf,
  42.            '%s',
  43.            pwidechar('Hello character world!'));  { picks widechar overload   }
  44.  
  45.   writeln(unicodestring(WideBuf));
  46.  
  47.  
  48.   writeln;
  49.   writeln('press ENTER/RETURN to end this program');
  50.   readln;
  51. end.
  52.  
Title: Re: No warning from FPC with ambiguous overload
Post by: MarkMLl on April 12, 2021, 11:20:43 am
When editing the source a programer  hit key "(" after "swprintf" and codetools code completion displays available overloaded versions.  This is enough to use the needed one.

Codetools is not maintained by the compiler team, so there is absolutely no guarantee that it will make the same choice.

MarkMLl
Title: Re: No warning from FPC with ambiguous overload
Post by: WooBean on April 12, 2021, 11:33:29 am
@MarkMLI

There is no need to establish some kind of cooperation between codetools code completion Authors and FPC core Team - code completion is showing my or anyone programer's code used for function declarations. So, it is responsibility of programmers to prepare proper parameters  to use exactly needed version of the functions.
Title: Re: No warning from FPC with ambiguous overload
Post by: 440bx on April 12, 2021, 11:35:37 am
When editing the source a programer  hit key "(" after "swprintf" and codetools code completion displays available overloaded versions.  This is enough to use the needed one.
No, that's incorrect. The selection of the correct overload is determined by the _format specifier_ not by the function parameters.

Specifically, if the format specifier had been "%S" instead of "%s", your change would result in the call not producing the correct result.

The _only_ way the compiler could make the correct determination is by inspecting the format specifier _and_ by knowing that swprintf normally expects a widechar string.  if it did that then, a "%s" would tell the compiler to pass a widestring while a "%S" would tell the compiler to pass a single byte character string and, the reverse if the function had been sprintf instead of swprintf.


it is responsibility of programmers to prepare proper parameters  to use exactly needed version of the functions.
Yes and, it is the compiler's responsibility to inform the programmer of ambiguous choices it made which it has no way of knowing are correct.
Title: Re: No warning from FPC with ambiguous overload
Post by: MarkMLl on April 12, 2021, 11:40:23 am
There is no need to establish some kind of cooperation between codetools code completion Authors and FPC core Team - code completion is showing my or anyone programer's code used for function declarations. So, it is responsibility of programmers to prepare proper parameters  to use exactly needed version of the functions.

The functions and parameters are entirely proper, and are accepted by the compiler without error, warning or other comment. That's the whole point of the thread.

MarkMLl
Title: Re: No warning from FPC with ambiguous overload
Post by: WooBean on April 12, 2021, 11:57:45 am
@440bx

Quote
Specifically, if the format specifier had been "%S" instead of "%s", your change would result in the call not producing the correct result.

You must be kidding - do you really think that FPC compiler Team will ever study internal (Windows API) formatting switches to decide which version of overloaded function is the needed one?

@MarkMLI
Quote
The functions and parameters are entirely proper, and are accepted by the compiler without error, warning or other comment. That's the whole point of the thread.

If parameters of function were properly prepared you would have no problems to call the needed one version. Try to compile and execute  a little changed by me your example.
 :)   

 
Title: Re: No warning from FPC with ambiguous overload
Post by: 440bx on April 12, 2021, 01:00:13 pm
@440bx

You must be kidding - do you really think that FPC compiler Team will ever study internal (Windows API) formatting switches to decide which version of overloaded function is the needed one?
No, I am not kidding.  That is precisely the point, the compiler cannot know what the correct overload is without inspecting the format specifier and it is completely unreasonable to expect the compiler to inspect the format specifier.  The result is, the compiler cannot know whether it should pass a widechar or char string and, since it doesn't know, if it decides on one of them, it should inform the programmer of its guess (sometimes euphemistically referred to as "preference") because that guess has about a 50% chance of being wrong, which for a compiler is pretty bad.

Just imagine, your code is logically perfect but you have only a 50% chance that what the compiler produces reflects what you coded and gives you no indication of the gamble it just handed you.  No hint or warning either to make it more interesting.  Even casinos give you a pamphlet (a hint/warning that the odds are not in your favor), the least a compiler should do is give a hint that code might not be in Kansas anymore.


Title: Re: No warning from FPC with ambiguous overload
Post by: WooBean on April 12, 2021, 01:27:12 pm
@440bx, @MarkMLI

A working code tells enaugh (compile and execute the code below):
Code: Pascal  [Select][+][-]
  1. program project3;
  2.  
  3. uses
  4.   stupidUnit;
  5.  
  6. var
  7.   WideChars: wideString;
  8. begin
  9.   WideChars:='Hello unicode world!';
  10.   writeln(stupid1(pWideChar(@WideChars[1])));
  11.   writeln(stupid1('ABCD'));
  12.   readln;
  13. end.
  14.  

[edited]
Output is:
called with pWideChar
called with pChar


Code: Pascal  [Select][+][-]
  1. unit stupidUnit;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. interface
  6. function stupid1(p:pWideChar):string; overload;
  7. function stupid1(p:pChar):string; overload;
  8.  
  9.  
  10.  
  11. implementation
  12. uses
  13.   Classes, SysUtils;
  14.  
  15. function stupid1(p:pWideChar):string; overload;
  16. begin
  17.   if p<>nil then  result:='called with pWideChar' else
  18.     result:='called with pWideChar(nil)';
  19.  
  20. end;
  21. function stupid1(p:pChar):string; overload;
  22. begin
  23.     if p<>nil then  result:='called with pChar' else
  24.     result:='called with pChar(nil)';
  25. end;
  26.  
  27.  
  28. end.  
  29.  

WooBean
 ;) ;)
 
Title: Re: No warning from FPC with ambiguous overload
Post by: MarkMLl on April 12, 2021, 01:31:46 pm
@WooBean: which of those is chosen? Why is it chosen? Can you guarantee that? Because one of the senior compiler team wouldn't be drawn beyond saying that it was implementation-defined.

MarkMLl
Title: Re: No warning from FPC with ambiguous overload
Post by: alpine on April 12, 2021, 01:40:55 pm
IMHO, the compiler should not be blamed for having difficulties interpreting an ambiguous statements. Overloaded subroutines can be the  source of big frustration both for the compiler and the programmer. Ask somebody with at least a modest experience in C++ :)

@440bx
Isn't it better that way:
Code: Pascal  [Select][+][-]
  1. function swprintf_wc({ _out_ } OutWideBuffer    : pwidechar;
  2.                   { _in_  } InFormatString   : pwidechar;
  3.                   { _in_  } InWidechars      : pwidechar)
  4.          : integer; cdecl; external ntdll name 'swprintf';
  5. function swprintf_c({ _out_ } OutWideBuffer    : pwidechar;
  6.                   { _in_  } InFormatString   : pwidechar;
  7.                   { _in_  } InAnsiChars      : pchar)
  8.          : integer; cdecl; external ntdll name 'swprintf';
  9.  

BTW, It is more related to the functions of varargs than to overloaded ones, IMO they are mainly C language prerogative.

Regards,
Title: Re: No warning from FPC with ambiguous overload
Post by: WooBean on April 12, 2021, 01:47:49 pm
@WooBean: which of those is chosen? Why is it chosen? Can you guarantee that? Because one of the senior compiler team wouldn't be drawn beyond saying that it was implementation-defined.

MarkMLl

I see you are too busy to compile several lines example ... .
Output of my example is

called with pWideChar
called with pChar
 

FPC has no hesitation which overloaded version to choose.

WooBean
 :D
Title: Re: No warning from FPC with ambiguous overload
Post by: MarkMLl on April 12, 2021, 02:18:25 pm
I see you are too busy to compile several lines example ... .

Yes, I am busy frankly.

And you have no understanding of what "implementation defined" implies. I'm afraid that using coloured text and no doubt the occasional cat video is no substitute.

MarkMLl
Title: Re: No warning from FPC with ambiguous overload
Post by: 440bx on April 12, 2021, 07:51:27 pm
IMHO, the compiler should not be blamed for having difficulties interpreting an ambiguous statements. Overloaded subroutines can be the  source of big frustration both for the compiler and the programmer. Ask somebody with at least a modest experience in C++ :)

@440bx
Isn't it better that way:
Code: Pascal  [Select][+][-]
  1. function swprintf_wc({ _out_ } OutWideBuffer    : pwidechar;
  2.                   { _in_  } InFormatString   : pwidechar;
  3.                   { _in_  } InWidechars      : pwidechar)
  4.          : integer; cdecl; external ntdll name 'swprintf';
  5. function swprintf_c({ _out_ } OutWideBuffer    : pwidechar;
  6.                   { _in_  } InFormatString   : pwidechar;
  7.                   { _in_  } InAnsiChars      : pchar)
  8.          : integer; cdecl; external ntdll name 'swprintf';
  9.  

BTW, It is more related to the functions of varargs than to overloaded ones, IMO they are mainly C language prerogative.

Regards,
The compiler isn't to blame for ambiguous statements.  What the compiler can legitimately be blamed for is making choices in situations that are not decidable and _not_ informing the programmer that it made an arbitrary choice that is not guaranteed in any way to be correct.  THAT is the problem, the compiler's silence when it made a decision that is simply arbitrary (calling it a "preference" doesn't change the situation.)

As far as the definitions you present, yes, of course it can be done that way but that's foregoes the compiler's abilities to overload definitions.  That's just a way of hiding the real problem which is, the compiler's failure to inform the programmer that it made an _arbitrary_ choice that may or may not be correct.



@Woobean

The problem is that the compiler doesn't tell you that a typecast is needed to get it right.  The compiler may make the wrong choice and not say anything to the programmer that it may have made an incorrect choice. 

Yes, you can typecast to get it right and, it would be much easier for the programmer to know a typecast is required to get it right if the compiler had the courtesy of pointing out that situation to the programmer.  That is problem, the lack of "courtesy" from the compiler.


Title: Re: No warning from FPC with ambiguous overload
Post by: MarkMLl on April 12, 2021, 10:05:37 pm
The compiler isn't to blame for ambiguous statements.  What the compiler can legitimately be blamed for is making choices in situations that are not decidable and _not_ informing the programmer that it made an arbitrary choice that is not guaranteed in any way to be correct.  THAT is the problem, the compiler's silence when it made a decision that is simply arbitrary (calling it a "preference" doesn't change the situation.)

I'd add- and I'm not attempting to criticise anybody here- that when I was discussing this sort of thing with @PascalDragon a few days ago nobody said "that's inadvisable" or "that's abusing the language and/or compiler"... it was just accepted as something that could be done and wasn't too outrageous.

Again I'd emphasise that I am not trying to be critical. But having multiple functions/procedures/methods in this context does not appear to be an unreasonable thing to do.

But from the other thread, FPC's decision-making process appears to be consistent within the scope of a single compiler, but indeterminate when multiple implementations are considered. And thinking about it, should a user assume that it is determined by the order of declarations in the interface part (or object definiiton) or the order of implementation, since the compiler appears happy for these to differ? And what about forward declarations?

I think that everybody agrees that this is not an error situation. But it really does merit a note or warning.

MarkMLl

Title: Re: No warning from FPC with ambiguous overload
Post by: ccrause on April 13, 2021, 08:57:45 pm
I think that everybody agrees that this is not an error situation. But it really does merit a note or warning.
I think there is merit in knowing what the compiler finds acceptable and what it finally chooses.  There is already some reporting build into the compiler around overload errors, so with a small tweak it is possible to get a list of feasible overloads followed by the specific overload chosen. Consider the following test case:
Code: Pascal  [Select][+][-]
  1. program Project1;
  2.  
  3. procedure proc1(a: int8);
  4. begin
  5.   writeln(a);
  6. end;
  7.  
  8. procedure proc1(a: int16);
  9. begin
  10.   writeln(a);
  11. end;
  12.  
  13. procedure proc1(a: string);
  14. begin
  15.   writeln(a);
  16. end;
  17.  
  18. begin
  19.   proc1(111);
  20. end.

The overload report for this is:
Code: Text  [Select][+][-]
  1. text.inc(623,10) Hint: Found declaration: $fpc_get_output:^Text;
  2. project1.lpr(5,3) Hint: Overload $fpc_get_output:^Text; selected for call.
  3. text.inc(978,11) Hint: Found declaration: $fpc_write_text_sint(LongInt;var Text;Int64);
  4. project1.lpr(5,3) Hint: Overload $fpc_write_text_sint(LongInt;var Text;Int64); selected for call.
  5. text.inc(721,11) Hint: Found declaration: $fpc_writeln_end(var Text);
  6. project1.lpr(5,3) Hint: Overload $fpc_writeln_end(var Text); selected for call.
  7. text.inc(623,10) Hint: Found declaration: $fpc_get_output:^Text;
  8. project1.lpr(10,3) Hint: Overload $fpc_get_output:^Text; selected for call.
  9. text.inc(978,11) Hint: Found declaration: $fpc_write_text_sint(LongInt;var Text;Int64);
  10. project1.lpr(10,3) Hint: Overload $fpc_write_text_sint(LongInt;var Text;Int64); selected for call.
  11. text.inc(721,11) Hint: Found declaration: $fpc_writeln_end(var Text);
  12. project1.lpr(10,3) Hint: Overload $fpc_writeln_end(var Text); selected for call.
  13. text.inc(623,10) Hint: Found declaration: $fpc_get_output:^Text;
  14. project1.lpr(15,3) Hint: Overload $fpc_get_output:^Text; selected for call.
  15. text.inc(880,11) Hint: Found declaration: $fpc_write_text_ansistr(LongInt;var Text;const RawByteString);
  16. project1.lpr(15,3) Hint: Overload $fpc_write_text_ansistr(LongInt;var Text;const RawByteString); selected for call.
  17. text.inc(721,11) Hint: Found declaration: $fpc_writeln_end(var Text);
  18. project1.lpr(15,3) Hint: Overload $fpc_writeln_end(var Text); selected for call.
  19. project1.lpr(8,11) Hint: Found declaration: proc1(SmallInt);
  20. project1.lpr(3,11) Hint: Found declaration: proc1(ShortInt);
  21. project1.lpr(19,3) Hint: Overload proc1(ShortInt); selected for call.

The list of feasible overloads point to their respective declarations, so it is easy to jump to the code in Lazarus, while the selected declaration is printed with the call location. The phrasing of the hints probably need some work, and the sequence of information may not be intuitive, but it shows what can be reported. Obviously the amount of information can become quite large, so I'm thinking that it should be controlled with a local switch to limit the amount of information that e.g. calling into the RTL will generate.

The compiler branch (https://github.com/ccrause/freepascal/tree/overloadhints) if anyone wants to play around with this feature.
TinyPortal © 2005-2018