Re: [PATCH] caret diagnostics (was: broken FE diagnostics wrt complex expressions)

["Joseph S. Myers" <joseph@codesourcery.com>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2507 bytes --]

On Thu, 14 Aug 2008, Manuel López-Ibáñez wrote:

> 2008/8/14 Joseph S. Myers <joseph@codesourcery.com>:
> >
> > But in any case the default should be the default with no configure
> > option, users liking it should find their makefiles work the same
> > everywhere and users not liking it can add the opposite option.
> 
> Then we are not going to get correct locations ever. New users do not

I do not see how your reply relates to the text you quote about not having 
a configure option, as opposed to the discussion of what the default 
should be.

> read the manual. Neither old users do. New functionality disabled by

I certainly did read the manual (the old "Using and Porting") when I first 
started to use GCC, identified those warning options that seemed good to 
be and put them in the standard set of warning options I use in my 
makefiles, and have revised that set from time to time for new versions 
and absed on experience.

> Moreover, caret diagnostics was mentioned as the way to solve the PRs
> that Aldy mentioned. If it is disabled by default, how does it solve
> anything? Why bother? I would really feel that I contributed to make

The solution is producing accurate location ranges, which can be used (a) 
to print more accurate expressions within the text of diagnostics in the 
existing style, (b) to print GCS-compliant ranges in text that IDEs can 
parse to highlight the relevant text in their editors (and we should 
expect that tools such as GCC and GDB are increasingly going to be used as 
a back end to other tools rather than just directly on the command line by 
users), and (c) for caret diagnostics for users liking those on the 
command line.  Caret diagnostics are only one of the styles in which the 
accurate location information can be used, and implementing an individial 
style is only a small part of the solution.  The PRs are about (a): cases 
where an expression text is displayed within the existing diagnostic text, 
badly.

Naturally all cases covered by (a) should have tests in the testsuite 
checking the right text is printed.  We should also make the testsuite 
able to test location ranges for diagnostics that don't include expression 
text for the relevant range, and then insist in patch review that tests of 
new front-end diagnostics appropriately assert the range involved, as well 
as converting existing tests to more precise assertions over time.

-- 
Joseph S. Myers
joseph@codesourcery.com