This is the mail archive of the gcc@gcc.gnu.org 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 (was: broken FE diagnostics wrt complex expressions)


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

> Even if the configure options do not control the compilation of the
> code, they should at least control the default. I think that, at least

No, whatever the default is there should definitely be no configure option 
to control it.  Configure options controlling such user-visible behavior 
as this are a very bad idea; users should not find the same options, 
makefiles etc. acting differently depending on what distribution of the 
same version of GCC they have.  It would be better to remove some 
configuration options than to add them: make GCC more confident it knows 
the right way to configure various things for each system and configure 
them the right way unconditionally.

> for development versions, the default should be on. We do want
> developers to realise when their new warning/error is pointing to the
> wrong location. Moreover, some user-friendly distributions may want to
> enable this by default. Therefore, I would argue to keep the configure
> options to determine the default value of -fdiagnostics-show-caret.

I argue the default should be output (a) compatible with consumers 
expecting a series of diagnostic lines following the GNU Coding Standards 
and (b) compact according to existing expectations of GCC output (one line 
per message instead of three or more, for front ends that have been doing 
that so far, but probably keeping carets for any front ends that have been 
using them with their own machinery).  Compatibility especially argues for 
keeping the existing format, but my experience is also that the main use 
of a diagnostic is to find the right line in an editor and only on a small 
proportion of occasions (when the warning option could be added to the 
compilation command manually) is it at all unclear what the problem is, 
such that more precise details (typically pointing into preprocessed 
source) would be useful: almost all the time caret diagnostics would make 
the bulk of diagnostic output into unnecessary noise.

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.

-- 
Joseph S. Myers
joseph@codesourcery.com

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