Bug 19542 - Broken F# Error Reports
Summary: Broken F# Error Reports
Alias: None
Product: Tools
Classification: Mono
Component: xbuild ()
Version: 3.4.0
Hardware: PC Mac OS
: Normal minor
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2014-05-05 21:00 UTC by Miguel de Icaza [MSFT]
Modified: 2014-05-09 20:04 UTC (History)
7 users (show)

Is this bug a regression?: ---
Last known good build:

Screenshot showing the error pad (744.34 KB, image/png)
2014-05-05 21:00 UTC, Miguel de Icaza [MSFT]
Repro solution (3.27 KB, application/zip)
2014-05-07 17:17 UTC, David Siegel

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Miguel de Icaza [MSFT] 2014-05-05 21:00:35 UTC
Created attachment 6738 [details]
Screenshot showing the error pad

Hey guys,

When compiling with the latest Xamarin Studio, instead of getting the one-line error messages parsed, we get the entire text output from the F# compiler, like this.

This should instead just show one line with the error message, and should not include the output of the compiler.
Comment 1 Dave Thomas 2014-05-06 07:55:52 UTC
Formatting of the error is performed upstream in XS I think

The F# addin does format compiler messages, but only when the "Use MSBuild build engine" option is unchecked.
Comment 2 Mikayla Hutchinson [MSFT] 2014-05-06 19:44:43 UTC
Looks to me like a bug in the FSharp MSBuild task. It should be passing --nologo to the compiler, else the logo makes the message unparsable by the MSBuild error parser.
Comment 3 donsyme 2014-05-07 07:31:13 UTC
The FSharp MSBuild task could indeed add --nologo. 

However it hasn't historically done that, so it seems like this must be a regression or chnge of behaviour in XS error parsing?

Adjusting the FSharp MSBuild task would be a very slow way to fix this: Microsoft provide the implementation of the task on Windows and so fixing this would require both a new version of Mono and a new OOB release from Microsoft, and all people using XS on Windows would have to be using that latest release.

I think an adhoc fix in the XS error parsing is going to be the economical way to fix this?


p.s. There is also an OtherFlags setting for the MSBuild task, which could be set on a template-by-template basis, but existing F# projects don't normally set that.
Comment 4 Lluis Sanchez 2014-05-07 09:52:35 UTC
When using the MSBuild engine XS doesn't do any parsing, it collects error and warning information using the MSBuild api.

In any case, I can reproduce this issue. Miguel, which Mono version do you have?
Comment 5 Miguel de Icaza [MSFT] 2014-05-07 10:04:42 UTC

This error was reported by David.   Since he was doing this with XS 5.0, I suspect he had whatever it is that we released to Alpha last week.

So this means that we need to fix this in xbuild?
Comment 6 Lluis Sanchez 2014-05-07 10:29:33 UTC
With the information I have, I agree with Michael that the issue seems to be in the FSharp MSBuild task.
Comment 7 donsyme 2014-05-07 10:53:26 UTC
From the screenshot looks like this is OSX/Mono.  I don't see any problems on Windows?  That might make a fix in the F# task feasible.
Comment 8 Mikayla Hutchinson [MSFT] 2014-05-07 11:11:55 UTC
Parsing of error/warning messages in the "standard" MSBuild format is handled by the MSBuild ToolTask that the Fsc task subclasses.

It's possible that this is a regression introduced by introduced by https://github.com/mono/mono/commit/7a2d2c247c481c291fed5f7f1213189d9426108a

However, Fsc *should* be using /nologo on all platforms (like the Csc and Vbc tasks do) since the logo is pointless in MSBuild output.
Comment 9 Miguel de Icaza [MSFT] 2014-05-07 12:17:18 UTC

Can you coordinate a fix for this?
Comment 10 donsyme 2014-05-07 14:43:27 UTC
FWIW I wasn't able to repo this on latest XS 5.0 alpha on OSX.  Some exact repro steps would be appreciated in case I'm doing something wrong.
Comment 11 Mikayla Hutchinson [MSFT] 2014-05-07 17:06:52 UTC
Looking at xbuild ToolTask, it splits the compiler output on Enviroment.NewLine and checks each line for error message, so I'm not sure how multiline output could be displayed.
Comment 12 David Siegel 2014-05-07 17:17:33 UTC
Created attachment 6752 [details]
Repro solution
Comment 13 Mikayla Hutchinson [MSFT] 2014-05-07 18:11:08 UTC
It looks like the "Tool exited with code X" message is only displayed when the exit code was nonzero and none of the lines parsed as errors, which implies that this was caused by the changes to the regex.
Comment 14 Mikayla Hutchinson [MSFT] 2014-05-07 18:37:54 UTC
Yeah, I can't repro on current alpha channel or on master. May be an environmental issue.
Comment 15 Mikayla Hutchinson [MSFT] 2014-05-07 18:50:14 UTC
Okay, was able to figure it out after looking at David's machine. The issue is that the path the projects in has () brackets which is confusing the error parsing regex.
Comment 16 Mikayla Hutchinson [MSFT] 2014-05-07 19:04:33 UTC
The regex seems to be specifically designed to exclude () from the pathname characters. Jon, any ideas about how to fix this?
Comment 17 Jonathan Pryor 2014-05-08 09:07:02 UTC
@mhutch: I haven't fully read the thread here, but current stable versions of Mono (3.2.x) do NOT have the xbuild fixes for proper error checking (Bug #14767), and afaik you need the (unreleased) Mono 3.4.x to get that fix.

Then there's Bug #19498 in which xbuild doesn't like '(' in pathnames, _also_ not in any stable Mono 3.2.x release but fixed in the unreleased Mono 3.4.x.

AFAIK, _either_ (both?) of these could be in play, and both are not fixed in Mono 3.2.x.

When's 3.4.x coming out? :-)
Comment 18 Mikayla Hutchinson [MSFT] 2014-05-08 11:55:27 UTC
Jon, this is with 3.4.0 and it's about the error parsing regex, not item paths.
Comment 19 Mikayla Hutchinson [MSFT] 2014-05-09 20:04:28 UTC
Fixed in https://github.com/mono/mono/commit/88cf2f1f929a8cdcb2ad5497c7242f8f76231828

Replaced the regex with a handwritten parser and added a substantial test suite to ensure MSBuild compatibility.