Am 15.05.2021 um 20:08 schrieb Ryan Joseph via fpc-devel:
On May 15, 2021, at 10:49 AM, Ryan Joseph wrote:
Also it looks like ChangeOwnerAndName isn't making the compiler happy.
Sorry for the noise, I figured out it was because the name had spaces. How
should I make the name then? I'm
Am 15.05.2021 um 18:27 schrieb Ryan Joseph via fpc-devel:
On May 13, 2021, at 2:38 PM, Sven Barth wrote:
Ah, you need to use ChangeOwnerAndName then and simply pass in the same name
you used for the constructor (cause otherwise it tries to use the name that is
currently stored in the
> On May 15, 2021, at 10:49 AM, Ryan Joseph wrote:
>
> Also it looks like ChangeOwnerAndName isn't making the compiler happy.
Sorry for the noise, I figured out it was because the name had spaces. How
should I make the name then? I'm doing this for now which is certainly unique
but it's not
> On May 15, 2021, at 10:27 AM, Ryan Joseph wrote:
>
> Looking at this again today and I have yet another question to confirm. I
> create one of the types using ctypesym.create but the others were just
> references from the system unit. We only want to change owner of the symbol I
> create,
> On May 13, 2021, at 2:38 PM, Sven Barth wrote:
>
> Ah, you need to use ChangeOwnerAndName then and simply pass in the same name
> you used for the constructor (cause otherwise it tries to use the name that
> is currently stored in the list).
Looking at this again today and I have yet
Am 12.05.2021 um 17:50 schrieb Ryan Joseph via fpc-devel:
On May 9, 2021, at 1:30 AM, Sven Barth wrote:
Essentially it will boil down to sym.ChangeOwner(pd.parast)
However you need to keep the Owner (which is different from what you change
with ChangeOwner) different as otherwise
> On May 9, 2021, at 1:30 AM, Sven Barth wrote:
>
> Essentially it will boil down to sym.ChangeOwner(pd.parast)
>
> However you need to keep the Owner (which is different from what you change
> with ChangeOwner) different as otherwise is_specialization of the procdef
> will not work
Ryan Joseph via fpc-devel schrieb am Sa.,
8. Mai 2021, 22:33:
>
>
> > On May 8, 2021, at 12:04 PM, Sven Barth
> wrote:
> >
> > You need to use ChangeOwner as well, but as I wrote you need to pay
> attention for which created symbol you do it at what time.
>
> Ok, maybe this is what I got wrong
> On May 8, 2021, at 12:04 PM, Sven Barth wrote:
>
> You need to use ChangeOwner as well, but as I wrote you need to pay attention
> for which created symbol you do it at what time.
Ok, maybe this is what I got wrong didn't use ChangeOwner. When you say "add
to" what exactly do you mean?
Am 22.04.2021 um 17:52 schrieb Ryan Joseph via fpc-devel:
On Apr 16, 2021, at 11:35 AM, Ryan Joseph wrote:
Got this all integrated and put up the changes to
https://bugs.freepascal.org/view.php?id=35261. Now I'm waiting for another
final review. :)
The next thing to do now is to handle a
Am 06.05.2021 um 17:33 schrieb Ryan Joseph via fpc-devel:
I found something sneaky I'd like to confirm before I decide what to do about
it.
1) "T" in TAnyClass is specialized as Integer from the first parameter with
TSomeClass (which is TAnyClass).
2) "U" is getting specialized as String by
I found something sneaky I'd like to confirm before I decide what to do about
it.
1) "T" in TAnyClass is specialized as Integer from the first parameter with
TSomeClass (which is TAnyClass).
2) "U" is getting specialized as String by looking at the parameters in
Compare() in which "U"(the
> On Apr 22, 2021, at 9:52 AM, Ryan Joseph wrote:
>
>> Got this all integrated and put up the changes to
>> https://bugs.freepascal.org/view.php?id=35261. Now I'm waiting for another
>> final review. :)
>
> The next thing to do now is to handle a memory leak. From the bug tracker:
I just
> On Apr 16, 2021, at 11:35 AM, Ryan Joseph wrote:
>
> Got this all integrated and put up the changes to
> https://bugs.freepascal.org/view.php?id=35261. Now I'm waiting for another
> final review. :)
The next thing to do now is to handle a memory leak. From the bug tracker:
> You
> On Apr 16, 2021, at 2:44 AM, Sven Barth via fpc-devel
> wrote:
>
> Yes, do that for now.
>
Got this all integrated and put up the changes to
https://bugs.freepascal.org/view.php?id=35261. Now I'm waiting for another
final review. :)
Regards,
Ryan Joseph
Ryan Joseph via fpc-devel schrieb am Fr.,
16. Apr. 2021, 00:38:
>
>
> > On Apr 14, 2021, at 3:49 PM, Ryan Joseph wrote:
> >
> > It works but it thinks this array is array of const also so it's too
> strict I believe.
> >
> > ['aaa', 'bbb'];
>
> About this, shouldn't we just be doing this? Any
> On Apr 14, 2021, at 3:49 PM, Ryan Joseph wrote:
>
> It works but it thinks this array is array of const also so it's too strict I
> believe.
>
> ['aaa', 'bbb'];
About this, shouldn't we just be doing this? Any array constructor that has
elements which are which are incompatible is "array
> On Apr 14, 2021, at 11:39 PM, Sven Barth wrote:
>
> Well, then I'll have to improve the check. But for now you can continue,
> right?
I can continue but if I include the check some tests will fail. Currently I've
only made some changes in create_unamed_typesym and now this check to reject
Am 14.04.2021 um 23:49 schrieb Ryan Joseph via fpc-devel:
On Apr 14, 2021, at 2:33 PM, Sven Barth wrote:
Had a bit of time to look at this. You can try the attached patch. You can then
check for both ado_IsConstructor and ado_IsArrayOfConst to detect such a mixed
array.
It works but it
> On Apr 14, 2021, at 2:33 PM, Sven Barth wrote:
>
> Had a bit of time to look at this. You can try the attached patch. You can
> then check for both ado_IsConstructor and ado_IsArrayOfConst to detect such a
> mixed array.
It works but it thinks this array is array of const also so it's too
Am 11.04.2021 um 23:38 schrieb Ryan Joseph via fpc-devel:
On Apr 11, 2021, at 3:33 PM, Sven Barth wrote:
Looking at it, it could be that there is a bug in
tarrayconstructornode.pass_typecheck that hasn't really surfaced yet... I'll
have to look at that first, but I don't know when I'll
> On Apr 11, 2021, at 3:33 PM, Sven Barth wrote:
>
> Looking at it, it could be that there is a bug in
> tarrayconstructornode.pass_typecheck that hasn't really surfaced yet... I'll
> have to look at that first, but I don't know when I'll have the time for that.
sure I'll just leave it as
Am 11.04.2021 um 22:27 schrieb Ryan Joseph via fpc-devel:
On Apr 10, 2021, at 9:47 AM, Ryan Joseph wrote:
Just checked and pass_typecheck is called before overloading but ado_IsVariant is simply never set
for that array. In tarraydef.GetTypeName you can see that "array of const" is
> On Apr 10, 2021, at 9:47 AM, Ryan Joseph wrote:
>
> Just checked and pass_typecheck is called before overloading but
> ado_IsVariant is simply never set for that array. In tarraydef.GetTypeName
> you can see that "array of const" is associated with many flags so maybe we
> need to make a
> On Apr 10, 2021, at 9:18 AM, Ryan Joseph wrote:
>
> I checked before and here's what I got. Maybe pass_typecheck hasn't been
> called yet? If not I'll have to reproduce that code and determine how it
> knows the elements are not uniform. Thanks.
Just checked and pass_typecheck is called
> On Apr 10, 2021, at 6:54 AM, Sven Barth wrote:
>
> As an additional note: if you take a look at
> tarrayconstructornode.pass_typecheck you can see that the array type always
> has the ado_IsConstructor set and if it contains of incompatible types the
> ado_IsVariant is set as well. So if
Am 10.04.2021 um 10:38 schrieb Sven Barth:
Am 10.04.2021 um 00:43 schrieb Ryan Joseph via fpc-devel:
On Apr 9, 2021, at 4:31 PM, Sven Barth via fpc-devel
wrote:
You mean what you did for is_array_literal? A pure array constructor
can be found with is_array_constructor, though it might be
Am 10.04.2021 um 00:43 schrieb Ryan Joseph via fpc-devel:
On Apr 9, 2021, at 4:31 PM, Sven Barth via fpc-devel
wrote:
You mean what you did for is_array_literal? A pure array constructor can be
found with is_array_constructor, though it might be better to use
is_open_array, cause someone
> On Apr 9, 2021, at 4:31 PM, Sven Barth via fpc-devel
> wrote:
>
> You mean what you did for is_array_literal? A pure array constructor can be
> found with is_array_constructor, though it might be better to use
> is_open_array, cause someone might pass an open array parameter to a generic
Am 09.04.2021 um 23:52 schrieb Ryan Joseph via fpc-devel:
On Apr 9, 2021, at 3:08 PM, Sven Barth wrote:
Possibly, yes...
You could provide the various utility functions in a separate patch.
Well I'm going to use them for this patch so they would all be batched together.
Any idea about the
> On Apr 9, 2021, at 3:08 PM, Sven Barth wrote:
>
> Possibly, yes...
>
> You could provide the various utility functions in a separate patch.
Well I'm going to use them for this patch so they would all be batched together.
Any idea about the "array of const" issue I raised in the other
Am 09.04.2021 um 18:12 schrieb Ryan Joseph via fpc-devel:
On Apr 8, 2021, at 11:37 PM, Sven Barth via fpc-devel
wrote:
That is because before the introduction of type helpers such functions weren't
really needed. Other mechanisms caught such constants, but for both type
helpers and these
I just realized one more type introspection related issue. This currently will
specialize as DoThis because the array constructor element type is
"shortint" as is derived from the first element 1. This of course is not
correct so I'd like to reject "array of const constructors" but I don't see
> On Apr 8, 2021, at 11:37 PM, Sven Barth via fpc-devel
> wrote:
>
> That is because before the introduction of type helpers such functions
> weren't really needed. Other mechanisms caught such constants, but for both
> type helpers and these implicit specializations it's hard to do it
Am 09.04.2021 um 04:20 schrieb Ryan Joseph via fpc-devel:
On Apr 8, 2021, at 3:53 PM, Sven Barth wrote:
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
> On Apr 8, 2021, at 3:53 PM, Sven Barth wrote:
>
> 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
Am 08.04.2021 um 19:28 schrieb Ryan Joseph via fpc-devel:
On Apr 7, 2021, at 1:56 PM, Ryan Joseph 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
Am 07.04.2021 um 23:21 schrieb Ryan Joseph via fpc-devel:
With the requested changes I believe some precedence rules have changed. These both should be "Can't
determine which overloaded function to call" errors or the non-generic should take precedence because the
functions are ambiguous (by
> On Apr 7, 2021, at 1:56 PM, Ryan Joseph 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
>
With the requested changes I believe some precedence rules have changed. These
both should be "Can't determine which overloaded function to call" errors or
the non-generic should take precedence because the functions are ambiguous (by
appearance at least). Currently the compiler thinks DoThis
> On Apr 7, 2021, at 1:42 PM, Sven Barth via fpc-devel
> wrote:
>
> Yes, we want to change that for two reasons:
> - the constant string might be larger than 255 characters
> - ShortString is worse for passing as a by-value parameter (which will be the
> default after all) than AnsiString or
Am 07.04.2021 um 18:16 schrieb Ryan Joseph via fpc-devel:
On Apr 6, 2021, at 11:34 PM, Sven Barth wrote:
In the second case the compiler will have the non-generic Test(String) due to the
implicit operator as well as Test(LongInt) due to the implicit
specialization. Here it will pick the
> On Apr 6, 2021, at 11:34 PM, Sven Barth wrote:
>
> In the second case the compiler will have the non-generic Test(String) due to
> the implicit operator as well as Test(LongInt) due to the implicit
> specialization. Here it will pick the generic one, because a call without a
> type
Am 06.04.2021 um 23:11 schrieb Ryan Joseph via fpc-devel:
On Apr 6, 2021, at 12:57 PM, Sven Barth wrote:
In the example you posted below, I agree with you, but that is not what I said.
Look at my example again:
Also could you please verify that $H+ isn't causing problems? The string
Am 06.04.2021 um 22:47 schrieb Ryan Joseph via fpc-devel:
On Apr 6, 2021, at 12:57 PM, Sven Barth wrote:
In this specific case the two functions also are *not* ambigous, because for the
non-generic Test the parameter requires an implicit conversion, but the implicit
specialization does
> On Apr 6, 2021, at 12:57 PM, Sven Barth wrote:
>
> In the example you posted below, I agree with you, but that is not what I
> said. Look at my example again:
Also could you please verify that $H+ isn't causing problems? The string
literal 'Hello World' is a short string but "String" is
> On Apr 6, 2021, at 12:57 PM, Sven Barth wrote:
>
> In this specific case the two functions also are *not* ambigous, because for
> the non-generic Test the parameter requires an implicit conversion, but the
> implicit specialization does not. For example if there would be a "Test(aArg:
>
Am 06.04.2021 um 17:45 schrieb Ryan Joseph via fpc-devel:
Finally some movement is happening on implicit function specialization and I'm
almost finished now except some questions about precedence have been raised
again. Initially I thought we decided on non-generic functions taking
precedence
Finally some movement is happening on implicit function specialization and I'm
almost finished now except some questions about precedence have been raised
again. Initially I thought we decided on non-generic functions taking
precedence in the case of *any* name collisions (the original thread
49 matches
Mail list logo
