Strange error when compiling project in XSharp 2.6

[leon-ts]

Hi,

When compiling the project with a new version of XSharp 2.6, a strange error occurred (or rather, in a strange place):

XS0029: Cannot implicitly convert type 'logic' to 'logic*'

The error points to the following place in the code:

Code: Select all

LOCAL dwMsg, i, nMax, n1, n2, crText AS DWORD

Attached is a tiny project with a chunk of code cut out to reproduce the problem.

[Chris]

Thanks Leonid, I can confirm the problem. Apparently there's a problem with passing LOGIC vars by reference, unfortunately we missed that. For now, please use REF instead of the @ operator for LOGICs:

IF oSearchControl:OnSearchText(cText, REF lItemChanged)

[robert]

Chris,
This is not just passing logic vars by reference, but it is passing logic vars by reference in a late bound call.
Leonid, is it possible to strongly type the variable ? Maybe by using an interface.
That would also make this code perform better !

Robert

[leon-ts]

Robert, Chris,

Note that the error points to line 5 (I am using VS2019). This line contains the declaration of a set of variables of type DWORD:

Code: Select all

LOCAL dwMsg, i, nMax, n1, n2, crText AS DWORD

I looked at this line in bewilderment and did not understand what had to do with LOGIC and the transfer of parameters in general. If the error pointed to a real line with an error (thanks to Chris for the hint), then I would probably guess the reason and take some action.

is it possible to strongly type the variable ? Maybe by using an interface.
That would also make this code perform better !

This is the old VO code transported to XSharp. Unfortunately, such code will still be found. The code in which I encountered the error today compiled without problems in XSharp 2.5b.

Best regards,
Leonid

[Chris]

Leonid,

Note that the error points to line 5 (I am using VS2019). This line contains the declaration of a set of variables of type DWORD:

Code: Select all

LOCAL dwMsg, i, nMax, n1, n2, crText AS DWORD

I looked at this line in bewilderment and did not understand what had to do with LOGIC and the transfer of parameters in general. If the error pointed to a real line with an error (thanks to Chris for the hint), then I would probably guess the reason and take some action.

Indeed, that makes it difficult to find the reason of the problem, I have included this info in the logged report:

https://github.com/X-Sharp/XSharpPublic/issues/493

[leon-ts]

Chris, thanks!
Are you planning to release a hotfix?

Best regards,
Leonid

[robert]

Leonid,
Let's fix this first!

Robert

[leon-ts]

Robert,

I just wanted to ask, what will we need to wait for fixes in the planned new version (in a month) or will you release a hot update?

The thing is, whatsnew for 2.6 says:

Passing parameters by reference with an @ sign was not working correctly for late bound method calls. This has been fixed.

But it turns out that this is not the case. Moreover, it even stopped compiling relative to the previous version.

Best regards,
Leonid

[robert]

Leonid,
I have created a fix for this. It was working correctly for locals of type usual and for locals of type VOSTRUCT or UNION but not for other types.
The automated tests are running now.
When there are no errors in the tests then we'll send you a zip with the changed compiler.

Robert

[Chris]

Hi Leonid,

To add to what Robert said: In the previous build, maybe you were not getting a compiler error, but in some cases such code did not work correctly at runtime (ie the vars passed by reference were not being updated when control returned to the calling code). See https://github.com/X-Sharp/XSharpPublic/issues/448

This was fixed, but it was for untyped/USUAL vars passed by reference, which is the most common case. Unfortunately we did not notice the problem with typed vars with different type than USUAL passed by reference in late bound calls because strangely enough none of the very large amount of code we are testing with was using this. Now it is added in our test suite, so this problem should not ever emerge again.