This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] caret diagnostics (was: broken FE diagnostics wrt complex expressions)
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