[PATCH] D73151: [analyzer] Fix handle leak false positive when the handle dies too early

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added inline comments.


================
Comment at: clang/test/Analysis/fuchsia_handle.cpp:80
+  zx_status_t status = zx_channel_create(0, &sa, &sb);
+  // expected-note at -1 {{Handle allocated through 2nd parameter}}
+  if (status == 0) { // expected-note {{Assuming 'status' is equal to 0}}
----------------
NoQ wrote:
> jroelofs wrote:
> > jroelofs wrote:
> > > @xazax.hun, @dcoughlin Is it expected that these diagnostics be non-deterministic? I'm seeing this test case fail sporadically [1] because sometimes the analyzer sees that the 3rd argument leaks, and other times it sees that the 2nd does.
> > > 
> > > The easy fix here would be to adjust the regex to be flexible against that difference, but I didn't want to cover up an underlying issue by committing that blindly:
> > > 
> > > ```
> > > // expected-note at -1 {{Handle allocated through (2nd|3rd) parameter}}
> > > ```
> > > 
> > > 1: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/17048/console
> > erm, wrong link. this is the correct one:
> > 
> > http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-expensive/17049/#showFailuresLink
> Hmm, no, these diagnostics shouldn't be non-deterministic. It's a bug. Thanks a lot for noticing!
> 
> Non-determinism in *notes* shouldn't be too bad. Also investigation may get pretty long because diagnostic sorting and de-duplication is a highly automated process. I believe we should cover up the problem to suppress buildbot failures and investigate when we can. I'll commit the cover-up.
rGc26f237cef1


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73151/new/

https://reviews.llvm.org/D73151