[Patch, Fortran] Show better error location

[Tobias Burnus]

Am 01.06.2013 16:06, schrieb Mikael Morin:
> For the redirection to "less", one can use "less -S".

Still, that does not help if the output is excessively long. Try some C 
(or C++) long code (e.g. 30,000 lines long), do a minor mistake there 
and run it through
   topformflat 0 x < in.c > out.c
and then run
   export COLUMNS=10000000000
   gcc out.c

You will be delighted to have first a warning message, then 100 kbytes 
of source code. Followed by 50 kbytes of spaces, followed by the ^ to 
show where the error is. and then it continues.

Thus, with less you either have pages over pages with the source code - 
or you have to scroll for ages to the right until you find the ^ and the 
problematic source location.

In the real world, such source code typically occurs for generated code 
- as no one is insane enough to write such kind of code manually. But 
also generated Fortran code looks rather ugly. Actually, generated code 
can have excessive line lengths: Nearly all compilers have flags to lift 
the line-length restriction (some even do so by default). But some 
compilers have a hard limit on the number of continuation lines.

As Fortran code usually has rather short lines, I admittedly still do 
not understand the problem which the patch wants to solve.

> For "tee", it depends on what comes behind. For the file case, one 
> doesn't know how wide the final display will be. It is easy to trim 
> afterwards, but the converse is not true (obviously)

Well, you still have the source code file. The point of showing the 
source code is to make it easier to see the mistake - not to output the 
whole file every time - with the error line somewhere hidden.

The real information is in the ERROR or WARNING message together with 
the file name and line number. The excerpt from the source code comes 
only on top to make it easier to see where the problem is. And here, it 
helps to be able to directly spot the problem - instead scrolling around.

But as stated before, it's mostly bikeshadding: There are arguments for 
both and it does not matter for most of the source code. As stated 
before, I am in favour of the current version. But I also don't oppose 
if the settings are changed.

  * * *

>> Build and regtested on x86-64-gnu-linux.
>> OK for the trunk?
> OK, thanks.

Thanks for the review!

Tobias,
who is still looking for someone to review his FINAL patch 
athttp://gcc.gnu.org/ml/fortran/2013-05/msg00134.html  (and possibly 
also the follow-up patch).