This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Caret diagnostics

On Tue, Apr 10, 2012 at 2:37 PM, Manuel LÃpez-IbÃÃez
<> wrote:
> On 10 April 2012 20:52, Gabriel Dos Reis <> wrote:
>> On Tue, Apr 10, 2012 at 11:46 AM, Manuel LÃpez-IbÃÃez
>> <> wrote:
>>> On 10 April 2012 00:28, Jason Merrill <> wrote:
>>>> On 04/09/2012 04:01 PM, Manuel LÃpez-IbÃÅez wrote:
>>>>> * It uses Âthe default cutoff as max_width, whatever it is (as
>>>>> controlled by -fmessage-length).
>>>>> * It uses the pretty-printer. The text cannot (should not) wrap
>>>>> because we still print only max_width chars at most.
>>>> Hmm, I think if pp_line_cutoff is 0 and we're on a terminal, we still want
>>>> to use COLUMNS to limit how much of the source we print.
>>> Like this?
>> There is a novelty in this new version that I don't think we discussed
>> before: automatic expansion of tabs to 8 hard space characters. ÂThat
>> number should not be hardcoded as there is no reason to believe a tab
>> character always expands to 8 space characters. ÂYou should check
>> the environment first; if not present the default expansion number should
>> be a symbolic constant as opposed to a magic number sprinkled all over the
>> places. ÂI would also encourage you to introduce more abstraction to
>> reduce the size of diagnostic_show_locus.
> There is no novelty, it has been there from the beginning, and now I
> realize it was a mistake to do the extra work to implement this.

I wonder how I missed it in the previous reviews.

> The GCS says: "Calculate column numbers assuming that space and all
> ASCII printing characters have equal width, and assuming tab stops
> every 8 columns"

That is GNU coding convention for GNU codes.  We do not require that
programs GCC accept have to adhere to GNU coding convention, not
should we.  An important aspect of diagnostic with caret is that we are
writing back to the user what she wrote, not what GNU wanted her
to write.

> So, in fact, libcpp is buggy for not implementing this (as can be seen
> in emacs). If/When libcpp is fixed, the column info will be correct
> for tabs. And then, one may care about printing tabs as anything
> different from a single space. But until then, a single space is a
> good as anything. In fact this is what is done in c-ppoutput.c.

I would not necessarily say that libcpp is buggy in this aspect.
However, I do agree that removing the tab expansion simplifies
the code and is better.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]