Ryan Joseph <generic...@gmail.com> schrieb am Di., 8. Okt. 2019, 23:00:
> > > > On Oct 8, 2019, at 11:32 AM, Sven Barth via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > 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)). > > 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? > 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. Regards, Sven >
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
