This is an archive of the discontinued LLVM Phabricator instance.

[CFG] Relax Wexceptions warning on rethrow
ClosedPublic

Authored by erichkeane on Oct 17 2017, 11:09 AM.

Details

Summary

As reported here: https://bugs.llvm.org/show_bug.cgi?id=34973

"catch(...)" should catch EVERYTHING, even a rethrow. This
patch changes the order in which things are checked to ensure
that a '...' catch will get a rethrow.

Diff Detail

Repository
rL LLVM

Event Timeline

erichkeane created this revision.Oct 17 2017, 11:09 AM

Have a question on the behavior here, see inline.

lib/Sema/AnalysisBasedWarnings.cpp
299 ↗(On Diff #119353)

The other potential fix here is to simply change this line here to "return true;". This would result the warning being suppressed on 'rethrow' if there is any catch statements.

I wonder what the opinion of the reviewers is on this one.

test/SemaCXX/warn-throw-out-noexcept-func.cpp
244 ↗(On Diff #119353)

Doh, I should have changed the name here... Still want your feedback on above though.

erichkeane edited the summary of this revision. (Show Details)

I've convinced myself that a re-throw with a catch around it should not be diagnosed, otherwise there is no way to suppress the warning in this case. It ends up being a false-positive in many cases.

aaron.ballman edited edge metadata.Oct 17 2017, 1:26 PM

I've convinced myself that a re-throw with a catch around it should not be diagnosed, otherwise there is no way to suppress the warning in this case. It ends up being a false-positive in many cases.

Wouldn't a catch-all handler suppress the warning in that case? e.g.,

void f() noexcept {
  try {
    throw; // rethrows
  } catch (int) {
    // We hope this catches it, and if it always does, then this is a fp warning.
  } catch (...) {
    // However, without cross-TU analysis, we can't know that detail and it seems plausible that
    // the active exception object is something else, so the catch-all is not unreasonable and adds
    // extra safety. The diagnostic (even if a fp) requires the developer to think about this case.
    assert(false);
  }
}
lib/Sema/AnalysisBasedWarnings.cpp
299 ↗(On Diff #119353)

I'm a little bit concerned about it, truth be told. The current behavior has false positives, and this patch trades those for false negatives. The question boils down to which is the more likely scenario. Rethrow from within a try block that catches the exception being rethrown seems like a rather unlikely scenario to me. Do you have examples of this being a false positive with real-world code?

I do agree that the catch-all handler should silence the diagnostic, however.

Wouldn't a catch-all handler suppress the warning in that case? e.g.,

Yep, you're right of course. I'll revert to my first patch and update this. I'd surmised that false-positives were worse than false-negatives, but since there is a trivial workaround, I'm ok with that. Thanks for the quick review!

lib/Sema/AnalysisBasedWarnings.cpp
299 ↗(On Diff #119353)

I don't have any examples, just the bug report.

erichkeane edited the summary of this revision. (Show Details)

Changes as requested by @aaron.ballman

aaron.ballman accepted this revision.Oct 17 2017, 1:54 PM

LGTM! Thank you for the fix!

This revision is now accepted and ready to land.Oct 17 2017, 1:54 PM
This revision was automatically updated to reflect the committed changes.