Bug 16576 - mcs does not handle relative #line filenames
Summary: mcs does not handle relative #line filenames
Status: RESOLVED FIXED
Alias: None
Product: Compilers
Classification: Mono
Component: C# ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Marek Safar
URL:
Depends on:
Blocks:
 
Reported: 2013-12-03 17:25 UTC by Mikayla Hutchinson [MSFT]
Modified: 2013-12-09 08:41 UTC (History)
1 user (show)

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

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:
Status:
RESOLVED FIXED

Description Mikayla Hutchinson [MSFT] 2013-12-03 17:25:45 UTC
mcs does not handle relative #line filenames, csc does

For example in the following project layout:

A.cs
Foo\B.cs
Foo\Bar.cs

Both the following directives in the file Bar.cs work fine in csc and are resolved to correct absolute paths in the build output and the debug symbols:

#line 1 "B.cs"
#line 1 "../A.cs"

However, mcs outputs them verbatim and thus they do not work correctly.
Comment 1 Mikayla Hutchinson [MSFT] 2013-12-03 17:33:39 UTC
By "build output" I mean file/line info in build errors.

VS somehow screws this up, probably the in-process compiler - it ends up with two near-identical versions of each error, one with the verbatim paths and one with the correct path. But csc and msbuild work fine.
Comment 2 Mikayla Hutchinson [MSFT] 2013-12-03 17:35:03 UTC
I would like this to be able to generate razor / t4 output that does not contain machine/user-specific paths, since they output files are always checked into source control.
Comment 3 Mikayla Hutchinson [MSFT] 2013-12-03 17:58:29 UTC
Okay, looks like mcs generates correct debug info but incorrect build output.
Comment 4 Marek Safar 2013-12-05 14:07:30 UTC
Do you need this for error/warning messages? There is command line option /fullpaths which does it.
Comment 5 Mikayla Hutchinson [MSFT] 2013-12-05 17:50:06 UTC
I guess I would work around it with /fullpaths, but it's still an issue of compat. csc works fine without the option, mcs does not.
Comment 6 Marek Safar 2013-12-06 07:37:57 UTC
I don't see any reason why pollute error message with full source path. If you need it just use the option for it.
Comment 7 Mikayla Hutchinson [MSFT] 2013-12-06 17:54:56 UTC
I'm not asking for the full path. I'm asking for the CORRECT relative path.

If I have a file Foo/Bar.cs, errors are reported in Foo/Bar.cs. If it includes #line 1 "Baz.t4", mcs reports errors in Baz.t4 (which is useless), csc reports errors in Foo/Baz.t4 (which is useful).
Comment 8 Marek Safar 2013-12-09 08:41:31 UTC
Fixed in master