[m-rev.] --no-line-numbers by default for us

[Peter Wang]

On Wed, 09 Dec 2015 10:44:55 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> 
> 
> On Wed, 9 Dec 2015 10:32:07 +1100, Peter Wang <novalazy at gmail.com> wrote:
> 
> > On Tue, 08 Dec 2015 18:54:51 +1100 (AEDT), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
> > > Would anyone object to committing this diff?
> > 
> > Will disabling line numbers not hinder writing of foreign code?
> 
> We almost never DO write new foreign procs anymore. On the rare occasions
> when we do, we tend to add only small pieces of e.g. C code, so that
> if the C compiler gives you an error message, it is trivial to find out
> what the problem is, since the current versions of gcc will echo the
> line with the bug. (Old versions didn't do that, of course.)

The problem is not so much finding the bug as having the editor jump to
the correct source file and line automatically.  But it is easy enough
to re-enable line numbers when desired.

> > I don't know why we produce so many #line directives for high-level C
> > though.  It should be enough to emit them around hand-written foreign
> > code.
> 
> Mostly because a single line of Mercury code will often yield
> more than one line of C code. A Mercury predicate declaration
> that fits on one line will get translated into a C function declaration
> with each argument on a separate line, so mmc generates a
> #line directive before each line just so the C compiler will
> consider every one of those lines to have the same line number.
> This is for the very rare case of the argument being of a
> foreign type, whose name itself may have a syntax error.

Since it is very rare and gcc echos the line when it does occur,
I think we should solve the readability issue for ALL projects by
default, by making --line-numbers only emit #line directives around
foreign code.

Peter