Non-permanent error XS1503 in X# 2.16

This forum is meant for questions and discussions about the X# language and tools
Post Reply
leon-ts
Posts: 431
Joined: Fri Feb 03, 2017 1:43 pm

Non-permanent error XS1503 in X# 2.16

Post by leon-ts »

Hi,
In version X# 2.16.0.5 (and 6) when compiling projects, it is very rare, but error XS1503 occurs.
For example:

Code: Select all

Error XS1503 Argument 1: cannot convert from 'dword' to 'int'
The error itself is correct in the places in the code it points to. But the fact is that the projects have an option that performs implicit type conversion (vo4). And such a conversion is performed and there is no error. But during some next compilation of the project, in the place where the compiler used to silently cope with such a conversion, an error 1503 suddenly occurs. I restart the project, recompile, and the error no longer occurs. In this case, one restart of the project does not always help. It seems that in some situations the vo4 setting temporarily resets or the compiler ignores it. But I can not catch this moment, on what it depends. So I can't make a reproducible example. This rarely happens.

Robert, can you tell me what I should pay attention to?
Best regards,
Leonid
leon-ts
Posts: 431
Joined: Fri Feb 03, 2017 1:43 pm

Non-permanent error XS1503 in X# 2.16

Post by leon-ts »

For clarity, I will show one of the examples of the manifestation of this problem:
Screenshot.png
Screenshot.png (155.36 KiB) Viewed 802 times
Screenshot original file:
Screenshot.zip
(101.51 KiB) Downloaded 147 times
Here some project "059.2" is being compiled. As a result, the compiler reports two cases of typecast error (circled in red). The vo4 option is enabled. At the same time, for some reason, it reports only two cases, although the next two lines (732 and 733) also contain similar operations with the same data types, but there is no problem for these lines.

Note:

Code: Select all

FUNCTION NTrimLong(liNum AS LONG) AS STRING
	RETURN liNum:ToString()

// Target class
PROTECT nLastRowNumWithTopOffsetCalculated AS DWORD
PROTECT nLastRowTopOffsetValue AS DWORD
PROTECT nLastRowNumWithTopOffsetCalculated_Rough AS DWORD
PROTECT nLastRowTopOffsetValue_Rough AS DWORD
Thus, according to the project "059.2", the compiler produced only these two errors. Further, the compilation continued on the project "06" (could not be compiled for obvious reasons) and I canceled the build of the solution.

The places and code where this problem manifests itself can be different. The above is just one example. On the next compilation, lines 730 and 731 will compile without error.

I noticed that usually the sequence of actions is as follows:
1. Place the cursor on the solution level.
2. Select the "Clean" item in the context menu. This will clean up the builds in all projects in the solution.
3. Remaining at the solution level, select "Build" from the context menu.

The specified sequence of actions does not always lead to a problem, but if the problem does occur, then most often with this sequence.
Best regards,
Leonid
User avatar
Chris
Posts: 4809
Joined: Thu Oct 08, 2015 7:48 am
Location: Greece

Non-permanent error XS1503 in X# 2.16

Post by Chris »

Hi Leonid,

I have also seen this a few times in the past months, with a specific project. I think it has to do with the compiler options, under some circumstances the compiler does not use the options passed to it, but it happens so rarely that it is very difficult to reproduce this so it can be fixed. Good thing is that it indeed usually happens once, so after a failed build, you can build again and it should work.
Chris Pyrgas

XSharp Development Team
chris(at)xsharp.eu
leon-ts
Posts: 431
Joined: Fri Feb 03, 2017 1:43 pm

Non-permanent error XS1503 in X# 2.16

Post by leon-ts »

Hi Chris,
This problem is annoying because you can't leave the compilation of a big solution and have to follow it from start to finish. For example, when you compile a large solution with many projects, it takes time. If you have fixed all the existing bugs and are doing a final rebuild for an external test or release, then while a large solution is being built for a long time, you can be distracted by other things. In our case, we cannot be distracted, since the mentioned error may suddenly appear, and the compilation will not take place. As a result, if you know that your entire solution is going to, for example, 20 minutes, and were distracted by this time, then returning and finding this random error, you lost this time.

I note that the parameters are not completely lost by the compiler.
Let me explain what I mean:
For example, there are 100 lines in the project in which implicit type conversion is performed. But when this random error occurs, the compiler only reports a few of these lines, not all of them. This may indicate that the parameters were passed to the compiler correctly, but already inside it in some situations they are lost.

I am ready to take the time to help you fix this problem if you give some mechanisms that will log it and I will send you the resulting logs. Of course, this is not a critical issue. After all, this is ultimately a bug that didn't exist before version 2.16.
Best regards,
Leonid
User avatar
robert
Posts: 4440
Joined: Fri Aug 21, 2015 10:57 am
Location: Netherlands

Non-permanent error XS1503 in X# 2.16

Post by robert »

Leonid,
I understand the gravity of the issue. We have already spent quite some time looking for the cause of the issue.
Maybe this is related to the fact that these compiler options now also can be changed with compiler pragmas?
This feature was not introduced in 2.16, but some small changes were made in this area.
The way it works now in the compiler is this:
- each prg is compiled into a so called "compilation unit"
- this compilation unit also has the list of pragmas in that file
- when we check a compiler option in the parser we get the line/column for the token or rule involved and look for all pragmas before that line for that particular compiler option. When we find one, then this setting is used. When we do not find one, then we fall back to the commandline option for that compiler option.
- when we check a compiler option in a later stage of the compiler we try to find the parser node for the syntax node that we are working on and do the same

Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
leon-ts
Posts: 431
Joined: Fri Feb 03, 2017 1:43 pm

Non-permanent error XS1503 in X# 2.16

Post by leon-ts »

Robert,
Thank you for the clarification.
These improvements in the compiler correlate with how the error manifests itself: does not take into account the option that is actually there.
Maybe in one of the future versions you will be able to add some logs to this area? Just not to forget about this error.

For example, if the compiler reports an error from the list of error codes that can be handled by settings, then write to the log what the original compiler options were, what options were used in the unit, and whether there were pragmas that change them (I definitely don’t have them, because I didn't know about them). In general, everything that will help to understand the cause of the error.
Best regards,
Leonid
Post Reply