<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Ryan Joseph <<a href="mailto:genericptr@gmail.com">genericptr@gmail.com</a>> schrieb am Di., 8. Okt. 2019, 23:00:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
> On Oct 8, 2019, at 11:32 AM, Sven Barth via fpc-pascal <<a href="mailto:fpc-pascal@lists.freepascal.org" target="_blank" rel="noreferrer">fpc-pascal@lists.freepascal.org</a>> wrote:<br>
> <br>
> I checked again. The thing is that in the compiler overload handling is done inside htypechk.tcallcandidates. Your patch weakens/changes that. So you'll have to completely rethink your solution to fit it into tcallcandidates (that should for example collect all suitable generics in addition to the non-generic ones (if any)). <br>
<br>
What is the entry point for this? My design was to intercept the dummy symbol and attempt to perform the specialization at that point and return a valid procsym so the parser could continue with its current code path. Are you saying I should allow the tcallcandidates.create to accept a dummy symbol instead of a procsym?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes, exactly that. It could also be that the parser picks up a non generic overload from another unit (due to the order of units in the uses section) and then you can *only* handle that in tcallcandidates. </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>