This is an archive of the discontinued LLVM Phabricator instance.

[clang-tidy] fix PR39167, bugprone-exception-escape hangs-up
ClosedPublic

Authored by JonasToth on Oct 4 2018, 3:55 AM.

Details

Summary

The check bugprone-exception-escape should not register
if -fno-exceptions is set for the compile options. Bailing out on non-cplusplus
and non-exceptions language options resolves the issue.

Event Timeline

JonasToth created this revision.Oct 4 2018, 3:55 AM

This should definitly be backported, as exception-escape is in 7.0 and it hangs up on no-except builds

Needs a test.

How shall i test it? It feels that this condition should have been there from the beginning on, as the check only makes sense in c++ and with exceptions.

Needs a test.

How shall i test it? It feels that this condition should have been there from the beginning on, as the check only makes sense in c++ and with exceptions.

I'm guessing you need a run line with -x c, and with -x c++ -fno-exceptions, not sure about the contents of the file, but the clang-tidy crashes are easy to creduce.

alexfh added a comment.Oct 4 2018, 7:48 AM

Have you figured out why exactly does the check hang? Disabling it for -fno-exceptions may just hide a logical problem in the check.

alexfh accepted this revision.Oct 4 2018, 7:50 AM

Have you figured out why exactly does the check hang? Disabling it for -fno-exceptions may just hide a logical problem in the check.

(disabling it for these cases seems to be the right thing to do anyways, but it might be nice to use the opportunity to investigate the possible issue deeper)

This revision is now accepted and ready to land.Oct 4 2018, 7:50 AM

Have you figured out why exactly does the check hang? Disabling it for -fno-exceptions may just hide a logical problem in the check.

(disabling it for these cases seems to be the right thing to do anyways, but it might be nice to use the opportunity to investigate the possible issue deeper)

I did not investigate further, as the fix was so straight forward. I did verify it works though and that it actually fixes the issue :)

Deeper analysis could be done by @baloghadamsoftware as the original author?

This revision was automatically updated to reflect the committed changes.
This revision was automatically updated to reflect the committed changes.

This patch does not fix the underlying issue. I do have a candidate that might cause it, but I am not sure if it is functionally preserving (tests seems to work though!). I think it is best if @baloghadamsoftware takes a look at it as well!