[PATCH] D33333: Emit warning when throw exception in destruct or dealloc functions which has a (possible implicit) noexcept specifier

[Jennifer Yu via Phabricator via cfe-commits]

jyu2 added a comment.

In https://reviews.llvm.org/D33333#761233, @aaron.ballman wrote:

> In https://reviews.llvm.org/D33333#761224, @rnk wrote:
>
> > Re: clang-tidy, I would rather implement this as a traditional compiler warning.
> >
> > In https://reviews.llvm.org/D33333#761208, @aaron.ballman wrote:
> >
> > > In https://reviews.llvm.org/D33333#761126, @jyu2 wrote:
> > >
> > > > As I said, I don't think checking throw type matching catch handler type is compiler's job.  I'd like either silence all warning for that.  What do you think?
> > >
> > >
> > > Consider the following cases:
> > >  ...
> > >  I think the expected behavior in these cases is reasonable (and can be done with a CFG) rather than manually looking at the scope stack like you're doing.
> >
> >
> > I agree with @jyu2, we should do something simple. I think it would be simple to handle all cases except for `h`, which requires semantic analysis to figure out if the thrown object would be caught by the catch parameter. Implementing that is more likely to introduce bugs in the compiler than it is to find bugs in user code.
>
>
> I'm not certain I agree with the assertion it's more likely to introduce bugs in the compiler than find bugs in user code. Machine-generated code runs into silly things like this, and it's nice to warn the user about it. However, it may be reasonable to do that in a follow-up patch -- but that patch is likely to have a lot of churn since it's not really plausible to implement with the way @jyu2 has structured this patch. By making this an analysis-based warning instead, that would alleviate my concerns (but would likely require implementing the CFG approach anyway).
>
> > I doubt we need the CFG for any of this. The later examples are all throwing exceptions from catch blocks, which is the same as not having an open try scope.
>
> Sure, if you cut out the cases that require a CFG, you don't need a CFG for it. :-P Use of a CFG would eliminate obvious false-positives such as `h()`.
>
> Also, there should be some tests with function-try-blocks.


Sure, I will add that.


https://reviews.llvm.org/D33333