[cfe-dev] Fwd: [cfe-commits] r133526 - /cfe/trunk/lib/Sema/SemaExpr.cpp

[Chandler Carruth]

Moving a conversation from a review thread to cfe-dev for broader comments.

Currently Clang has a consistent practice of emitting a fixit suggestion
note which silences the warning (without changing semantics) first, followed
by any alternative suggestions. This seems a bit counter intuitive, as in
many (most?) cases, the alternative suggestion is more likely what the user
intended.

After discussing this on IRC with dgregor, he agreed and raised another
perspective that I find compelling for inverting the current policy: if
there is a fixit suggestion note which merely silences the compiler, it
should be *last*.

< dgregor> I do agree that always putting "silence the compiler" last would
be better… essentially, one could imagine the user reading each of the
notes, shaking his head, and then clicking on the last one "oh, shut up, I
know what I'm doing"

Thoughts? If there is general agreement with the strategy, I'm willing to
revisit my patch, implementing the policy consistently across all of our
warnings.
-Chandler

---------- Forwarded message ----------
From: Chandler Carruth <chandlerc at gmail.com>
Date: Tue, Jun 21, 2011 at 11:34 AM
Subject: Re: [cfe-commits] r133526 - /cfe/trunk/lib/Sema/SemaExpr.cpp
To: Douglas Gregor <dgregor at apple.com>
Cc: cfe-commits at cs.uiuc.edu


On Tue, Jun 21, 2011 at 11:23 AM, Douglas Gregor <dgregor at apple.com> wrote:

> I'm not a big fan of this change. In general, we've taken the approach that
> the "silence the warning" option is always first.


Ahh. Is that documented anywhere? It's not enforced by tests that I can
see... Anyways, didn't realize there was any policy.


I actually find this fairly unfortunate across the board. Most of the cases
where we have an alternative to silencing the warning, it's a more likely
alternative. It'd seem nice to invert the policy (silence comes last), but
maybe that can't be changed at this late stage.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110621/fdec6229/attachment.html>