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'Robert, can you tell me what I should pay attention to?
Non-permanent error XS1503 in X# 2.16
Non-permanent error XS1503 in X# 2.16
Hi,
In version X# 2.16.0.5 (and 6) when compiling projects, it is very rare, but error XS1503 occurs.
For example:
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?
In version X# 2.16.0.5 (and 6) when compiling projects, it is very rare, but error XS1503 occurs.
For example:
Robert, can you tell me what I should pay attention to?
Best regards,
Leonid
Leonid
Non-permanent error XS1503 in X# 2.16
For clarity, I will show one of the examples of the manifestation of this problem:
Screenshot original file:
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:
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.
- Screenshot.png (155.36 KiB) Viewed 863 times
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
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
Leonid
Non-permanent error XS1503 in X# 2.16
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.
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
XSharp Development Team
chris(at)xsharp.eu
Non-permanent error XS1503 in X# 2.16
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.
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
Leonid
Non-permanent error XS1503 in X# 2.16
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
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
The Netherlands
robert@xsharp.eu
Non-permanent error XS1503 in X# 2.16
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.
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
Leonid