On Thu, 2018-01-25 at 18:53 +0000, Bernd Edlinger wrote:
> Hi,
>
> as PR diagnostic/84034 shows, source files with
> dos style line endings can cause a glitch in the
> terminal emulation that erases the source line that
> is supposed to be shown.
>
> That happens when the colorizing escape sequences are
> printed between the CR and the LF. Apparently the LF is
> being ignored and thus the following line overwrites
> everything from the last source line.
>
>
> The following patch fixes the visual glitch by handling
> a CR '\r' like a TAB '\t' character.
>
>
> Bootstrapped and reg-rested in x86_64-pc-linux-gnu.
> OK for trunk?
Thanks for working on this.
[BEGIN BRAIN-DUMP:
Before gcc 6, we handled this case by printing (e.g. gcc 5):
/tmp/t.c: In function ‘test’:
/tmp/t.c:5:20: warning: suggest parentheses around ‘&&’ within ‘||’ [-
Wparentheses]
(d && b > e) &&
^
where all lines would end with LF, apart from the quoted source line,
which would end with CR+LF.
>From gcc 6 onwards, the lines all end with LF, apart from quoted source
lines, which end with:
CR + (end-colorization) + LF.
What's happening is that layout::print_source_line etc treat the CR as
non-whitespace, and prints it. Then layout::print_newline () prints
the end-colorization and LF.
Presumably we *don't* want to preserve that mixed-ending behavior in
our output from gcc 5 and earlier descibed above; that seems like an
accident of the old implementation, and doesn't seem useful.
Your patch effectively turns the CR before the LF into trailing
whitespace, stopping the CR from being printed, turning it into just:
(end-colorization) + LF
and thus fixing the glitch.
END BRAIN-DUMP]
The patch is OK.
Thanks
Dave
