Q: Debug/Diagnostics Mode

[matthid]

Is there currently only diagnostics / debug mode for the FCS component?

Time and time again I run into problems when using FCS and then I feel like I could use some logging or just more info what the compiler is doing instead of error FS0193: internal error: or whatever.

This doesn't need to be the default, it could be controlled by an undocumented environment variable for example.

This might be even a problem in the compiler code-base itself. But I mostly have this problems when using FCS therefore I opened the issue here.

In the past I have used custom builds like https://github.com/matthid/FSharp.Compiler.Service/commits/improve_error or https://github.com/matthid/FSharp.Compiler.Service/commits/improve_fcs_logging to help myself in such situations but this really is a frustrating experience for several reasons (one is that building this component time and time again frustrating in itself).

So my question basically is. Would a PR fixing the following issues be accepted:

• Remove Exception Hiding -> Use Inner Exceptions to properly propagate underlying exception objects. (failwithf is really a bad choice in propagating errors)
• Use existing logging infrastructure and allow users to plugin their own logging (or just enable it to print to stdout)

To be more concrete:

• Which logging framework would be acceptable to use (you can see that I used .NetFrameworks TraceSource for this in my branch)?
• Should this go against visualfsharp?
• Any things I need to consider to get this accepted?
• What would be the preferred way to enable such a debug/diagnostic mode?

Maybe there is already a way I was missing?

/cc @dsyme @cloudRoutine

[cloudRoutine]

To make it easier for people to get access to a debug build we could make a package for it that's only published on an appveyor feed.

But apart from that I think we could do a lot to improve the logging and diagnostic outputs of FCS

[dsyme]

@matthid I almost exclusively rely on either

1. For exceptions: turning on "stop on all CLR exceptions" in the Visual Studio debugger, also turning off "Just My Code". It's frustrating that Mono doesn't appear to have a really easy-to-use equivalent, maybe I'm missing it though (I don't edit the compiler on Linux/Mac very much)

2. For general testing: using the scripting approach in the tests\service tests

[matthid]

@dsyme yes I agree that's the best approach when you can reproduce the problem on your windows developer machine. This discussion is what we do in the other cases (which apparently I hit quite often for some reason)

[cloudRoutine]

For FCS out in the wild we're up a creek without a paddle, failing CI servers, as mono is want to do, build tools failing on devs using unfamiliar setups, and if you wanted to embed F# in an app to use as a scripting language it's not particularly easy to get back useful information if things start failing.

[matthid]

Just a collection of issues where this issue kept ME (others possibly just resigned already, its just too hard) on my toes and would have helped me to at least produce better bug reports or find workarounds faster:

• error FS0218: Unable to read assembly 'System.Runtime.dll' #619 (without @ncave that one would probably still be open)
• FCS is trying to load a reference assembly on mono. #763
• Improve Error message for InternalUndefinedItemRef #421 (It's currently just not important enough to track down without an easy way to get insights)
• error FS0193: internal error: Illegal characters in path. dotnet/fsharp#1224 (same as 421, probably will never be fixed)

Note that some of those bug reports took me hours or days to create (often with specially customized FCS builds involved). Just because I know that reporting "I get error FS0193: internal error" is a waste of time. It really shouldn't be THAT difficult to provide a good bug report for the heart or the F# ecosystem.

Two out of those 4 are still open ...

[matthid]

Maybe it's enough to upload a debug build on some nuget (appveyor?) feed and document

Debug.AutoFlush <- true
Debug.Listeners.Add(new TextWriterTraceListener(System.Console.Out)) |> ignore

That would already improve the situation dramatically (IMHO). However it would only improve the situation for FCS and not the rest of the ecosystem (like Visual Studio).

I'd propose that whenever we upload a version X.Y.Z we upload a debug build X.Y.(Z+1)-alpha001 to AppVeyor (/cc @forki for the versioning suggestion). This way we don't mess with nuget cache and stuff...

[dsyme]

I'd propose that whenever we upload a version X.Y.Z we upload a debug build X.Y.(Z+1)-alpha001 to AppVeyor (/cc @forki for the versioning suggestion). This way we don't mess with nuget cache and stuff...

That totally makes sense. Please just add the debug builds to the AppVeyor build process?

[dsyme]

Even just a debug version of FSharp.Compiler.Serrvice and nothing else, along with PDBs.

[dsyme]

Closing as fixed