[Mono-bugs] [Bug 594541] New: xbuild dies if a compiler outputs an error with slightly different spacing

[bugzilla_noreply at novell.com]

http://bugzilla.novell.com/show_bug.cgi?id=594541

http://bugzilla.novell.com/show_bug.cgi?id=594541#c0


           Summary: xbuild dies if a compiler outputs an error with
                    slightly different spacing
    Classification: Mono
           Product: Mono: Tools
           Version: 2.4.x
          Platform: x86-64
        OS/Version: Ubuntu
            Status: NEW
          Severity: Normal
          Priority: P5 - None
         Component: xbuild
        AssignedTo: jankit at novell.com
        ReportedBy: eli at wavemarket.com
         QAContact: mono-bugs at lists.ximian.com
          Found By: ---
           Blocker: ---


Created an attachment (id=352956)
 --> (http://bugzilla.novell.com/attachment.cgi?id=352956)
source & project files for test steps

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8)
Gecko/20100214 Ubuntu/9.10 (karmic) Firefox/3.5.8

Xbuild seems to be using an overly specific regex to parse error lines from
compilers. The result is that gmcs works fine, but vbnc (which uses almost
exactly the same error format, but is lacking two spaces) causes xbuild to
crash with a parsing exception if there were any compiler errors at all.

Reproducible: Always

Steps to Reproduce:
1. Make sure xbuild (2.4.2.3), gmcs (2.4.2.3), and vbnc (2.4.2) are installed.
2. Edit Microsoft.VisualBasic.targets as described in bug 594526, since
otherwise nothing will compile.
3. Create a .cs file and a .vb file that each contain a syntax error.
4. Create .csproj and .vbproj projects that each compile their respective file.
5. Run xbuild on each project.
Actual Results:  
The C# project builds as expected, showing the syntax error in the CoreCompile
step, but the VB project dies in the CoreCompile step with the following
exception:
System.FormatException: Input string was not in the correct format
  at System.Int32.Parse (System.String s) [0x00000] 
  at Microsoft.Build.Utilities.ToolTask.ParseOrigin (System.String origin,
System.String& filename, System.Int32& lineNumber, System.Int32& columnNumber,
System.Int32& endLineNumber, System.Int32& endColumnNumber) [0x00000] 
  at Microsoft.Build.Utilities.ToolTask.LogEventsFromTextOutput (System.String
singleLine, MessageImportance importance) [0x00000] 
  at Microsoft.Build.Utilities.ToolTask.RealExecute (System.String pathToTool,
System.String responseFileCommands, System.String commandLineCommands)
[0x00000] 
  at Microsoft.Build.Utilities.ToolTask.ExecuteTool (System.String pathToTool,
System.String responseFileCommands, System.String commandLineCommands)
[0x00000] 
  at Microsoft.Build.Utilities.ToolTask.Execute () [0x00000] 
  at Microsoft.Build.BuildEngine.TaskEngine.Execute () [0x00000] 
  at Microsoft.Build.BuildEngine.BuildTask.Execute () [0x00000] 

If you edit the .vb file to remove the syntax error, it builds fine. But if
there is *any* error of any kind in the .vb file, xbuild crashes with the same
exception as above (and does not tell you what the error was).

Expected Results:  
Xbuild would report the compiler error and not crash.

Running gmcs and vbnc outside of xbuild shows a slight difference in the format
of their error output:

gmcs:
$FILENAME.cs($LINE,$COLUMN): error CS$ERRNUM: $ERRORDESC

vbnc:
$ABSOLUTEPATH/$FILENAME.vb ($LINE,$COLUMN) : Error VBNC$ERRNUM: $ERRORDESC

The FormatException suggests that xbuild is trying to parse out either the
line/column numbers or the error number, and failing because its regex doesn't
work for the vbnc format.

I'm calling this an xbuild bug rather than a vbnc bug, because the format
difference is very slight and looks like it still ought to be parseable - and
in any case, it seems like if xbuild sees something it doesn't know how to
parse, it could just display it as is rather than crashing.

-- 
Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.