Best practice to handle error XS7038

This forum is meant for questions and discussions about the X# language and tools
Jan
Posts: 8
Joined: Wed Mar 16, 2022 8:19 am
Location: Germany

Best practice to handle error XS7038

Post by Jan »

We are currently migrating a project from Vulcan to XSharp. After eliminating all errors, we are getting a new error:

Code: Select all

XS7038	Failed to emit module 'CrefoFact-debug': Unable to determine specific cause of the failure.
We are also getting some thousand warnings (huge project). What is the best way to handle XS7038?

Thanks,

Jan
User avatar
Chris
Posts: 4593
Joined: Thu Oct 08, 2015 7:48 am
Location: Greece

Best practice to handle error XS7038

Post by Chris »

Hi Franz,

There were a couple errors like that which were fixed in the latest build, but can't be sure if those apply to your code as well. Due to the nature of this problem, I am afraid the only reason to confirm if this is fixed now, or let us debug, find and fix the problem in the compiler in case it is not already solved, is to zip and send us your code so we can test it in our machines.

.
Chris Pyrgas

XSharp Development Team test
chris(at)xsharp.eu
jeromegorlick
Posts: 7
Joined: Tue Aug 03, 2021 11:45 am

Best practice to handle error XS7038

Post by jeromegorlick »

Hey, we are in a similar situation, unlikely we would be able to get permission to send our code for testing, what is the time line estimated for the updated version of x# to be released?
User avatar
Chris
Posts: 4593
Joined: Thu Oct 08, 2015 7:48 am
Location: Greece

Best practice to handle error XS7038

Post by Chris »

For subscribers, new builds become available every month or so (latest one was released 2 weeks ago). Not sure about when will be the next public build, will need to discuss and decide on that.

If there's no way to send the code, then you could try to spot the problem manually like this: Create a copy of all your code/project and in that copy, start deleting/disabling large pieces of code, until the error goes away. When it no longer happens, you will know what caused it and you can tell us so it can be fixed in the compiler. Sometimes the problem can be found quickly this way, but sometimes in might also take a lot of time I am afraid. It's the nature of this problem, unfortunately there's no information available in the compiler to report, in order to make it easier to spot what causes it.

Edit: Just to be clear, we do not need to receive the whole code of an application in order to debug the problem here. Only the source code for the specific project/library that produces this, will be enough. Would just need of course all the other dlls (binaries) that the library depends on, so we can reproduce the problem.

.
Chris Pyrgas

XSharp Development Team test
chris(at)xsharp.eu
User avatar
robert
Posts: 4279
Joined: Fri Aug 21, 2015 10:57 am
Location: Netherlands

Best practice to handle error XS7038

Post by robert »

Jerome,
We can signed an NDA when that is needed to look at the source code.

Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
jeromegorlick
Posts: 7
Joined: Tue Aug 03, 2021 11:45 am

Best practice to handle error XS7038

Post by jeromegorlick »

Hey Robert, thanks for the clarification, I ended up finding the Module that was causing the library to fail building, I've excluded it for now as I am only doing a POC and if we get to a point where we are ready to proceed with full product conversion then If we hit the same error again we will certainly consider getting all the appropriate agreements in place to ensure we can proceed with conversion.
sjsepan
Posts: 3
Joined: Sun Oct 23, 2022 1:45 am

Best practice to handle error XS7038

Post by sjsepan »

As the OP did not provide an example, I am willing to submit mine, as it is open-source.
I just ran into this issue today, in a simple app to try out WinForms in X#.
i am running XIDE 2.16 in Windows & SP1 in VirtualBox 6.1.38 on Linux Mint 21.1.
I have attached a zip file of the project.
The issue occurs when I un-comment line 81 in FrmMain.prg, and goes away of that line is commented.

Steve S



 
Attachments
XSharpForms.zip
(83.32 KiB) Downloaded 49 times
User avatar
Chris
Posts: 4593
Joined: Thu Oct 08, 2015 7:48 am
Location: Greece

Best practice to handle error XS7038

Post by Chris »

Hi Steve,

Thanks for the report, problem confirmed and logged! Should be fixed soon.
Btw, unfortunately there can be different reasons for this error, so fixing this case does not guarantee it will not happen again, with different code. But we are trying to find and fix all similar cases (which shouldn't be too any now).
Chris Pyrgas

XSharp Development Team test
chris(at)xsharp.eu
User avatar
robert
Posts: 4279
Joined: Fri Aug 21, 2015 10:57 am
Location: Netherlands

Best practice to handle error XS7038

Post by robert »

Chris, Steve,
The reason for this problem is the following:
Roslyn (C#) detects this problem (the missing initializer for the const field) in the parser.
We (X#) have our own parser and produce a parse tree that we pass to Roslyn for further processing.
We did not catch this during parsing, and the Roslyn backend "trusts" that an error like this was caught during the parse phase, which obviously did not happen, and no longer reports the error.

I will adjust our parser to detect this at parse time.
This will now report:

Code: Select all

error XS0145: A const field requires a value to be provided
Robert
XSharp Development Team
The Netherlands
robert@xsharp.eu
sjsepan
Posts: 3
Joined: Sun Oct 23, 2022 1:45 am

Best practice to handle error XS7038

Post by sjsepan »

Thanks! Will adjust my Const declaration accordingly.
Post Reply