aaron.ballman added a comment. 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. https://reviews.llvm.org/D33333 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
