change the location_t type, DECL_SOURCE_LINE etc

[Fergus Henderson]

On 04-Dec-2002, Per Bothner <per@bothner.com> wrote:
> Fergus Henderson wrote:
> > The longest line is about 2300 characters.
> 
> Column numbers would probably not be very useful for generated C code.

I suspect it would be the other way around.
The wider the lines are, the more useful column numbers are,
and files with very wide lines are usually automatically generated.

The times I really wish gcc supported column numbers is when debugging
errors in macro-intensive code.  The trouble comes when you get an
error at the point of the macro invocation, but have no idea which part
of the body of the macro is causing the problem.  Typically what I do
then is generate the `.i' file, remove the #line directives, rename
it to `tmp.c' and recompile it.  Then I find the error message points
to a 2000-character line, so I edit the tmp.c file again, piping the
relevent function through `indent' to split up long lines.  (I'd run
the whole file through `indent', except that the program doesn't seem
to cope with files containing very long lines...)  Finally after a bit
of this sort of hacking I'm able to figure out which part of the `.i'
file is causing the error, and can then trace it back to the offending
macro in the source code.  There has to be a better way...

> In any case, it appears to me that line numbers in such C code are
> useless except to debug the Mercury compiler itself.

Not entirely.  Mercury allows users to write in-line C code in their
Mercury source files.  So the generated C file contains both
code which is automatically generated by the Mercury compiler,
and also C code fragments that the user wrote which are copied verbatim
into the generated C file.  (In this respect it's similar to what happens
with lex and yacc.)  Sometimes users make mistakes such as putting
unterminated comments or string literals in their C code fragments
or defining macro names which happen to conflict with identifiers used
in the generated code.  This can lead to error messages showing up
in the generated code.  Users who are debugging such problems need
to see which part of the generated code had problems in order to then
track down which part of their own code was the ultimate cause.

> Line numbers
> relative to the C code would be useless for debugging Mercury code.
> I assume you emit #line directives, in which case the size of
> the C code is irrelevant.

We do emit #line directives by default.
However, we don't emit a #line directives for the generated code --
instead we only emit #line directives before and after the user-written
C code fragments.  The #line directive after such a fragment just
resets the filename and line number back to the physical line in the file.

The reason that we do this is that the line numbers are only being used
for C compiler error messages, not for gdb.  If there are C errors in
the generated code, it's much better to point the user at the generated C
code which had a problem rather than pointing them at the corresponding
part of their Mercury source, since the problem can only be debugged
at the C level not the Mercury level.

> If we start storing column numbers, I think i makes sense to disable
> column numbers after a #line directive.

There are three different uses of #line directives:

	(1) immediately before a line of code copied verbatim from the
	    user's source file

	(2) immediately before a line of generated code which
	    conceptually corresponds to some part of the user's source file,
	    but which has been munged in some way (e.g. translated from
	    a different language)

	(3) immediately before a line of generated code which does not
	    correspond to any part of the user's source file,
	    to undo the effects of previous #line directives
	    and reset the logical file and line so that they
	    point back to the physical file again.

In case (2), it makes sense to disable column numbers.
In cases (1) and (3), it does not.

Case (3) can be detected by checking whether the line number and file name
in the #line directive match the physical file and line number; if they do,
column numbers shold be (re)enabled.

Unfortunately the C #line directive syntax provides no way to distinguish
cases (1) and (2).  I suppose it is best to disable column numbers in
cases (1)/(2) since it is better to provide less information in case (1)
than to provide misleading information in case (2).  In the long term
it might be worth considering some extension to the C #line directive
syntax to distinguish case (1).

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.