[cfe-dev] -ferror-limit omits part of last error message

Nikola Smiljanic popizdeh at gmail.com
Fri Aug 12 09:36:27 PDT 2011


Here is a patch that fixes the problem. I'll send one more with test cases
after the weekend. Is there a place where I can find similar test case?

On Fri, Aug 12, 2011 at 6:01 PM, Douglas Gregor <dgregor at apple.com> wrote:

>
> On Aug 11, 2011, at 3:02 PM, Nikola Smiljanic wrote:
>
>
> On Thu, Aug 11, 2011 at 7:07 PM, Douglas Gregor <dgregor at apple.com> wrote:
>
>>
>> This doesn't look right… it looks like it'll allow *all* notes to be
>> printed, even if the warning/error preceding that note was suppressed. What
>> we really want is for the notes corresponding to the last displayed error to
>> be displayed, but subsequent notes should still be suppressed.
>>
>> - Doug
>>
>
>
> You're right. It seems that this logic is already in place but it doesn't
> work and here's why: The error is emitted and delayed diagnostic is set
> (fatal error). So when ReportDelayed() is called it emits the fatal error
> but it still has delayed diagnostic set (itself) which causes another
> ReportDelayed to be called, and this one defeats the logic.
>
> The fix would be to reset DelayedDiagID before reporting it, like this:
>
> // store the object returned by Report in order to make its destructor run
> after DelayedDiagID is set to zero
> void Diagnostic::ReportDelayed() {
>   DiagnosticBuilder diagBuilder = Report(DelayedDiagID);
>   diagBuilder << DelayedDiagArg1 << DelayedDiagArg2;
>   DelayedDiagID = 0;
> }
>
> // reset DelayedDiagID before calling Report, but create the temporary to
> save the value
> void Diagnostic::ReportDelayed() {
>   int temp = DelayedDiagID;
>    DelayedDiagID = 0;
>   Report(temp) << DelayedDiagArg1 << DelayedDiagArg2;
> }
>
> // pass DelayedDiagID as the argument (this is passing its own member as an
> argument)
> void Diagnostic::ReportDelayed(int id) {
>   DelayedDiagID = 0;
>   Report(id) << DelayedDiagArg1 << DelayedDiagArg2;
> }
>
> The first one is the most reasonable one for me. What do you think?
>
>
> The first one seems reasonable. Can you update your patch with this fix +
> test cases?
>
> - Doug
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110812/42a948f9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: error-limit_clipping_notes.patch
Type: application/octet-stream
Size: 511 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110812/42a948f9/attachment.obj>


More information about the cfe-dev mailing list