Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
Created attachment 6738 [details]
Screenshot showing the error pad
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.
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.
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.
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.
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?
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?
With the information I have, I agree with Michael that the issue seems to be in the FSharp MSBuild task.
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.
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.
Can you coordinate a fix for this?
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.
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.
Created attachment 6752 [details]
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.
Yeah, I can't repro on current alpha channel or on master. May be an environmental issue.
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.
The regex seems to be specifically designed to exclude () from the pathname characters. Jon, any ideas about how to fix this?
@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? :-)
Jon, this is with 3.4.0 and it's about the error parsing regex, not item paths.
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.