Here’s what I have so far with some some tests included now. It’s complete in
it’s current form but I see what you mean about extending tcallcandidates. I
looked over everything again but right now I don’t see exactly how to achieve
that. I took the approach to take the dummy type sym and parse
I’ve looked into this more today and I don’t see how we can get around needing
a typesym for specializations.
For example:
generic procedure DoThis(msg: T);
begin
end;
var
a: array of char;
begin
DoThis(a);
Is going to specialize as DoThis(a). “array of char” is (for
lack
> On Feb 28, 2019, at 1:44 PM, Sven Barth via fpc-devel
> wrote:
>
> Right now I don't remember your changes, but it might be that you're using
> the wrong approach: You shouldn't need to match anything by yourself as the
> required infrastructure is already in place. You should extend
Am 28.02.2019 um 03:11 schrieb Ryan Joseph:
Sending this again to see if it gets through (posts getting blocked again).
On Feb 26, 2019, at 2:43 PM, Ryan Joseph wrote:
In my implicit generic specialization code I have one place where I get a
string const node (stringconstn) which the
I think that last message came through but I didn’t see what I quoted. Here’s
the original question:
In my implicit generic specialization code I have one place where I get a
string const node (stringconstn) which the resultdef is arraydef (not stringdef
like I would expect). I then need to
Sending this again to see if it gets through (posts getting blocked again).
> On Feb 26, 2019, at 2:43 PM, Ryan Joseph wrote:
>
> In my implicit generic specialization code I have one place where I get a
> string const node (stringconstn) which the resultdef is arraydef (not
> stringdef like
