Page MenuHomePhabricator

RedDocMD (Deep Majumder)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 24 2021, 12:52 AM (21 w, 1 d)

Recent Activity

Yesterday

RedDocMD added a comment to D104616: [analyzer][WIP] Model comparision methods of std::unique_ptr.

The only method that I think can be realistically modelled is == (and thus !=). If both the operands refer to the same unique_ptr, we know == returns true. If they are not the same, the only way == can return true if the two smart pointers were initialized from the same raw pointer. This is of course a fatal bug in itself. So perhaps we can ignore this case and only consider the first case.
The ordering operators I guess can't be handled because there is no way to statically tell in general the address of some value. We have the following deductions, nevertheless, mathematically:
Let ptr1 and ptr2 be two std::unique_ptr objects.
If (ptr1 == ptr2) is true:

  • ptr1 < ptr2 is false
  • ptr1 > ptr2 is false
  • ptr1 <= ptr2 is true
  • ptr1 >= ptr2 is true

If (ptr1 == ptr2) is false, we can't say anything really.

Sun, Jun 20, 11:24 PM · Restricted Project
RedDocMD requested review of D104616: [analyzer][WIP] Model comparision methods of std::unique_ptr.
Sun, Jun 20, 11:10 PM · Restricted Project

Sat, Jun 19

RedDocMD added a comment to D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

Do the above tests pass when your new evalCall modeling is enabled?

The analyzer doesn't seem to be able to make up its mind.

member-constructor.cpp:15:5: warning: FALSE [debug.ExprInspection]
    clang_analyzer_eval(*P->p == 0);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
member-constructor.cpp:15:25: note: Assuming the condition is false
    clang_analyzer_eval(*P->p == 0);
                        ^~~~~~~~~~
member-constructor.cpp:15:5: note: FALSE
    clang_analyzer_eval(*P->p == 0);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
member-constructor.cpp:15:5: warning: TRUE [debug.ExprInspection]
    clang_analyzer_eval(*P->p == 0);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
member-constructor.cpp:15:25: note: Assuming the condition is true
    clang_analyzer_eval(*P->p == 0);
                        ^~~~~~~~~~
member-constructor.cpp:15:5: note: TRUE
    clang_analyzer_eval(*P->p == 0);
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 warnings generated.
Sat, Jun 19, 11:11 AM · Restricted Project

Fri, Jun 18

RedDocMD abandoned D103434: [analyzer] Allow visitors to run callbacks on completion.

I am closing this since it has been addressed much better by the patches from @vsavchenko.

Fri, Jun 18, 11:51 AM · Restricted Project
RedDocMD updated the diff for D104300: [analyzer] Handle std::swap for std::unique_ptr.

Some more refactoring

Fri, Jun 18, 11:49 AM · Restricted Project
RedDocMD added inline comments to D104300: [analyzer] Handle std::swap for std::unique_ptr.
Fri, Jun 18, 11:47 AM · Restricted Project
RedDocMD added a comment to D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

I believe there are a couple of comments that are done but not marked accordingly.
I agree with Artem, if we could craft code that fails due to not calling ctors, we should probably include them in the tests, even if they don't reflect the desired behavior they are a great source of documentation what is missing.

Fri, Jun 18, 10:52 AM · Restricted Project
RedDocMD updated the diff for D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

Little changes, a failing test

Fri, Jun 18, 10:51 AM · Restricted Project
RedDocMD added a comment to D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

I would suppose that constructor calls are properly handled. (ie, member constructors are called properly).

Do the above tests pass when your new evalCall modeling is enabled?

Fri, Jun 18, 10:45 AM · Restricted Project
RedDocMD added inline comments to D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.
Fri, Jun 18, 10:34 AM · Restricted Project

Thu, Jun 17

RedDocMD updated the diff for D104300: [analyzer] Handle std::swap for std::unique_ptr.

Marking and un-marking interestingness

Thu, Jun 17, 12:14 AM · Restricted Project

Wed, Jun 16

RedDocMD added a comment to D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

I would suppose that constructor calls are properly handled. (ie, member constructors are called properly).
As for modelling destructors, there is a separate problem - since we don't have a Stmt, the postCall handler keeps on crashing.

Wed, Jun 16, 10:04 PM · Restricted Project
RedDocMD added inline comments to D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.
Wed, Jun 16, 9:57 PM · Restricted Project
RedDocMD updated the diff for D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

Added more info to the TODO

Wed, Jun 16, 8:57 PM · Restricted Project

Tue, Jun 15

RedDocMD added a comment to D104300: [analyzer] Handle std::swap for std::unique_ptr.

I have gotten rid of notes for the time being.
The trouble is that, we were not figuring out whether the null-pointer de-reference was occurring due to the null value being swapped with the current pointer.
We just assumed that. So I am guessing we would need a visitor to figure that out? (Hooray for Valeriy!)
Or is there a simpler solution?

Tue, Jun 15, 11:38 AM · Restricted Project
RedDocMD updated the diff for D104300: [analyzer] Handle std::swap for std::unique_ptr.

Refactored common code, removed note emission

Tue, Jun 15, 11:34 AM · Restricted Project
RedDocMD added a comment to D104300: [analyzer] Handle std::swap for std::unique_ptr.

The current implementation of how notes are emitted in handleSwap is broken. Consider the following code:

#include <memory>
Tue, Jun 15, 11:23 AM · Restricted Project
RedDocMD added inline comments to D104300: [analyzer] Handle std::swap for std::unique_ptr.
Tue, Jun 15, 11:21 AM · Restricted Project
RedDocMD retitled D104300: [analyzer] Handle std::swap for std::unique_ptr from [analyzer] Handle `std::swap` for std::unique_ptr to [analyzer] Handle std::swap for std::unique_ptr.
Tue, Jun 15, 10:49 AM · Restricted Project
RedDocMD retitled D104300: [analyzer] Handle std::swap for std::unique_ptr from [analyzer] Handle `std::swap` to [analyzer] Handle `std::swap` for std::unique_ptr.
Tue, Jun 15, 10:48 AM · Restricted Project
RedDocMD added a comment to D104300: [analyzer] Handle std::swap for std::unique_ptr.

I am not entirely satisfied with the note that is being emitted currently from the std::swap handling (its ripped off from the note emitted for std::unique_ptr::swap).
Any suggestions?

Tue, Jun 15, 8:08 AM · Restricted Project
RedDocMD requested review of D104300: [analyzer] Handle std::swap for std::unique_ptr.
Tue, Jun 15, 8:05 AM · Restricted Project
RedDocMD updated the diff for D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

Fixed up meaning of make_unique_for_overwrite, use getConjuredHeapSymbolVal.

Tue, Jun 15, 6:53 AM · Restricted Project
RedDocMD added inline comments to D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.
Tue, Jun 15, 6:49 AM · Restricted Project

Fri, Jun 11

RedDocMD updated the diff for D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

Fixed up technique used to find inner pointer type, put TODO's

Fri, Jun 11, 9:21 PM · Restricted Project
RedDocMD updated the diff for D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

Removed un-necessary check

Fri, Jun 11, 9:51 AM · Restricted Project
RedDocMD retitled D103750: [analyzer] Handle std::make_unique for SmartPtrModeling from [analyzer][WIP] Handle std::make_unique for SmartPtrModeling to [analyzer] Handle std::make_unique for SmartPtrModeling.
Fri, Jun 11, 2:51 AM · Restricted Project
RedDocMD added inline comments to D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.
Fri, Jun 11, 2:50 AM · Restricted Project
RedDocMD updated the diff for D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

Fixed up tests, now also runnning on C++20

Fri, Jun 11, 2:50 AM · Restricted Project
RedDocMD added a comment to D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

How do I set the C++ standard while running a test?

Fri, Jun 11, 1:20 AM · Restricted Project
RedDocMD updated the diff for D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

Added tests

Fri, Jun 11, 1:07 AM · Restricted Project
RedDocMD updated the diff for D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

Put changes discussed in the meeting, tests to come in next revision

Fri, Jun 11, 12:13 AM · Restricted Project

Mon, Jun 7

RedDocMD added a comment to D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

Nice. Looks like I have something to read up on. Turns out, I end up learning something new in C++ every now and then. 😃

Mon, Jun 7, 8:04 PM · Restricted Project
RedDocMD added a comment to D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

Ugh, this entire checkBind hack was so unexpected that I didn't even recognize evalCall. What prevents you from doing everything in evalCall? No state traits, no nothing, just directly take the this-region and attach the value to it?

Mon, Jun 7, 11:52 AM · Restricted Project
RedDocMD added a comment to D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

Yes I think you should totally do an evalCall() here. The function has no other side effects apart from making a pointer so it's valuable to fully model it so that to avoid unnecessary store invalidations.

Mon, Jun 7, 11:05 AM · Restricted Project
RedDocMD added inline comments to D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.
Mon, Jun 7, 11:04 AM · Restricted Project
RedDocMD updated the diff for D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

Made stylistic refactors

Mon, Jun 7, 11:01 AM · Restricted Project

Sun, Jun 6

RedDocMD updated the diff for D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

Fixed git history

Sun, Jun 6, 9:14 AM · Restricted Project
RedDocMD updated the diff for D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

Reformatted code

Sun, Jun 6, 9:10 AM · Restricted Project
RedDocMD added a comment to D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

You can always create a new symbol to represent the inner pointer. Something like this already happens, when you have a unique_ptr formal parameter and call get on it.

Sun, Jun 6, 9:08 AM · Restricted Project
RedDocMD added a comment to D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

The drawback of the current approach is that we are not using the following piece of information:

std::unique_ptr created from std::make_unique is not null (to begin with)

I am not being able to use this info since I don't have access to the raw pointer, so cannot create a SVal and then constrain the SVal to non-null.
Any suggestions @NoQ, @vsavchenko , @xazax.hun, @teemperor?

Sun, Jun 6, 7:19 AM · Restricted Project
RedDocMD updated the diff for D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

Fixed binding of SVal to variable

Sun, Jun 6, 7:15 AM · Restricted Project

Sat, Jun 5

RedDocMD updated the summary of D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.
Sat, Jun 5, 11:25 AM · Restricted Project
RedDocMD updated the diff for D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.

Accounting for std::make_unique_for_overwrite

Sat, Jun 5, 11:23 AM · Restricted Project
RedDocMD retitled D103750: [analyzer] Handle std::make_unique for SmartPtrModeling from [analyzer] Handle std::make_unique for SmartPtrModeling to [analyzer][WIP] Handle std::make_unique for SmartPtrModeling.
Sat, Jun 5, 11:20 AM · Restricted Project
RedDocMD requested review of D103750: [analyzer] Handle std::make_unique for SmartPtrModeling.
Sat, Jun 5, 5:46 AM · Restricted Project

Fri, Jun 4

RedDocMD added a comment to D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling.

Judging by this line in the LikelyFalsePositiveSuppressionBRVisitor::finalizeVisitor() method, it seems that the bug report is squelched when the visitor encounters an ExplodedNode which corresponds to a LocationContext, whose associated Decl lies in std namespace. I guess, by default, the option to suppress warnings from the std library is enabled. Which makes sense, except in this case since unique_ptr is in std and it is being used in that function, the bug report is suppressed.

Fri, Jun 4, 1:02 AM · Restricted Project

Thu, Jun 3

RedDocMD added a comment to D103434: [analyzer] Allow visitors to run callbacks on completion.

I was thinking a lot about this problem after our last call, and even though StoppableVisitor helps to solve the problem that we have, it is extremely unclear when this callback is called and should be called.
I decided to restore the balance (and rid of all younglings, maybe) and put together this interface: D103605. I still need to migrate the existing code into the new architecture, but it can be done incrementally.

Thu, Jun 3, 3:39 AM · Restricted Project

Wed, Jun 2

RedDocMD added a comment to D97183: [analyzer] Add NoteTag for smart-ptr get().

Important question from @vsavchenko:

Wed, Jun 2, 11:19 AM · Restricted Project
RedDocMD updated the diff for D97183: [analyzer] Add NoteTag for smart-ptr get().

Moved visitor entirely to SmartPtrChecker.cpp, other refactors, better naming.

Wed, Jun 2, 11:16 AM · Restricted Project
RedDocMD added inline comments to D97183: [analyzer] Add NoteTag for smart-ptr get().
Wed, Jun 2, 11:15 AM · Restricted Project
RedDocMD added a comment to D103434: [analyzer] Allow visitors to run callbacks on completion.

The following things are now done:

Wed, Jun 2, 9:06 AM · Restricted Project
RedDocMD updated the diff for D103434: [analyzer] Allow visitors to run callbacks on completion.

trackExpressionValue recieving callback, passing it to ReturnVisitor

Wed, Jun 2, 9:02 AM · Restricted Project

Tue, Jun 1

RedDocMD added inline comments to D103434: [analyzer] Allow visitors to run callbacks on completion.
Tue, Jun 1, 9:58 PM · Restricted Project

Mon, May 31

RedDocMD added a comment to D103434: [analyzer] Allow visitors to run callbacks on completion.

Note: This patch is only partially done.

Mon, May 31, 11:00 PM · Restricted Project
RedDocMD requested review of D103434: [analyzer] Allow visitors to run callbacks on completion.
Mon, May 31, 10:57 PM · Restricted Project

Thu, May 27

RedDocMD added inline comments to D97183: [analyzer] Add NoteTag for smart-ptr get().
Thu, May 27, 11:22 AM · Restricted Project
RedDocMD added inline comments to D97183: [analyzer] Add NoteTag for smart-ptr get().
Thu, May 27, 1:42 AM · Restricted Project
RedDocMD added a comment to D97183: [analyzer] Add NoteTag for smart-ptr get().

My bad! I forgot to submit the replies.

Thu, May 27, 1:35 AM · Restricted Project
RedDocMD added inline comments to D97183: [analyzer] Add NoteTag for smart-ptr get().
Thu, May 27, 1:34 AM · Restricted Project

Wed, May 26

RedDocMD updated the diff for D97183: [analyzer] Add NoteTag for smart-ptr get().

Removed extra include

Wed, May 26, 10:47 PM · Restricted Project
RedDocMD updated the diff for D97183: [analyzer] Add NoteTag for smart-ptr get().

More refactoring

Wed, May 26, 10:41 PM · Restricted Project

Sun, May 23

RedDocMD added a comment to D97183: [analyzer] Add NoteTag for smart-ptr get().

I have put in the refactors, @teemperor.

Sun, May 23, 11:54 AM · Restricted Project
RedDocMD updated the diff for D97183: [analyzer] Add NoteTag for smart-ptr get().

Removed unnecessary include

Sun, May 23, 11:53 AM · Restricted Project
RedDocMD updated the diff for D97183: [analyzer] Add NoteTag for smart-ptr get().

Refactors to make code more stylistically accurate

Sun, May 23, 11:52 AM · Restricted Project

May 21 2021

RedDocMD added a comment to D97183: [analyzer] Add NoteTag for smart-ptr get().

Right, @teemperor, I will do the refactors once we figure out how to utilize trackExpressionValue() here (because that will eliminate quite a bit of code from GetNoteVisitor, so no point in refactoring those bits).

May 21 2021, 11:48 AM · Restricted Project

May 20 2021

RedDocMD updated the diff for D97183: [analyzer] Add NoteTag for smart-ptr get().

Removed un-necessary includes

May 20 2021, 11:59 AM · Restricted Project
RedDocMD added inline comments to D97183: [analyzer] Add NoteTag for smart-ptr get().
May 20 2021, 11:34 AM · Restricted Project
RedDocMD updated the diff for D97183: [analyzer] Add NoteTag for smart-ptr get().

Code clean up

May 20 2021, 11:34 AM · Restricted Project

May 19 2021

RedDocMD updated the diff for D97183: [analyzer] Add NoteTag for smart-ptr get().

Removed unnecessary includes

May 19 2021, 10:33 PM · Restricted Project
RedDocMD updated the diff for D97183: [analyzer] Add NoteTag for smart-ptr get().

Added a test for multiple get's

May 19 2021, 10:28 PM · Restricted Project

May 3 2021

RedDocMD added a comment to D97183: [analyzer] Add NoteTag for smart-ptr get().

@NoQ ?

May 3 2021, 1:25 AM · Restricted Project

Apr 28 2021

RedDocMD added a comment to D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling.
In D98726#2721228, @NoQ wrote:

when the visitor encounters an ExplodedNode

Weird. finalizeVisitor() accepts not any node but the error node. Your screenshot suggests that the error node is not in the standard library but in user code. Might it be that there are multiple error nodes and you're looking at the wrong one? As usual, you can set conditional breakpoints by node IDs.

Apr 28 2021, 6:50 AM · Restricted Project
RedDocMD added a comment to D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling.
In D98726#2721228, @NoQ wrote:

when the visitor encounters an ExplodedNode

Weird. finalizeVisitor() accepts not any node but the error node. Your screenshot suggests that the error node is not in the standard library but in user code. Might it be that there are multiple error nodes and you're looking at the wrong one? As usual, you can set conditional breakpoints by node IDs.

Apr 28 2021, 2:27 AM · Restricted Project

Apr 27 2021

RedDocMD added a comment to D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling.

Judging by this line in the LikelyFalsePositiveSuppressionBRVisitor::finalizeVisitor() method, it seems that the bug report is squelched when the visitor encounters an ExplodedNode which corresponds to a LocationContext, whose associated Decl lies in std namespace. I guess, by default, the option to suppress warnings from the std library is enabled. Which makes sense, except in this case since unique_ptr is in std and it is being used in that function, the bug report is suppressed.

Apr 27 2021, 3:12 AM · Restricted Project

Apr 26 2021

RedDocMD added a comment to D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling.

The call to PathSensitiveBugReport::markInvalid() is triggered by LikelyFalsePositiveSuppressionBRVisitor::finalizeVisitor(). So I guess we need to see now why the visitor thinks this is a false positive.

Apr 26 2021, 10:59 PM · Restricted Project

Apr 24 2021

RedDocMD added a comment to D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling.

As you can see here, the bug note is attached in the second case (please refer to my previous comment), but somehow, it doesn't finally show up as a bug.
Weird.

Apr 24 2021, 2:53 AM · Restricted Project

Apr 23 2021

RedDocMD added a comment to D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling.

Okay, this is alarming.
The following code yields a leak warning:

#include <iostream>
#include <memory>
Apr 23 2021, 9:42 PM · Restricted Project
RedDocMD added a comment to D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling.

I think something is wrong about the way we are investigating this or I don't understand the MallocChecker.
The following doesn't yield a bug report! => https://godbolt.org/z/Y57G7zE5j

Apr 23 2021, 8:56 PM · Restricted Project

Apr 21 2021

RedDocMD added a comment to D97183: [analyzer] Add NoteTag for smart-ptr get().

@NoQ?
(I actually should remove some extra includes and extra member fields)

Apr 21 2021, 11:57 AM · Restricted Project

Apr 20 2021

RedDocMD added a comment to D97183: [analyzer] Add NoteTag for smart-ptr get().

@NoQ, I have changed to the visitor that you suggested.

Apr 20 2021, 11:01 AM · Restricted Project
RedDocMD updated the diff for D97183: [analyzer] Add NoteTag for smart-ptr get().

Changed to a different visitor

Apr 20 2021, 10:56 AM · Restricted Project
RedDocMD added a comment to D97183: [analyzer] Add NoteTag for smart-ptr get().

It's important to realize that with pure static analysis it is absolutely impossible to reliably report a bug more severe than dead code. Any form of static analysis only ever finds code that doesn't make sense. It cannot make assumptions about how often the code is executed in practice or how severe and impactful the bug is to the users of the program under analysis. When we report anything that doesn't directly scream "dead code", like null dereference, we're still always implicitly saying "This code doesn't make sense because it either has dead parts or _____". In fact we should probably do a better job at managing expectations because users do become upset when we promise them use-after-frees but in reality only find dead code that "would have caused use-after-frees if it was ever run".

Apr 20 2021, 10:51 AM · Restricted Project

Apr 19 2021

RedDocMD added a comment to D97183: [analyzer] Add NoteTag for smart-ptr get().

For the following function:

void foo(std::unique_ptr<A> P) {
  A* praw = P.get();
  A* other = praw;
  if (other) {}
  P->foo();
}

Where do we expect a note? Where praw is initialized, where other is initialized or both?

Apr 19 2021, 10:54 AM · Restricted Project

Apr 3 2021

RedDocMD retitled D98726: [analyzer] Enabling MallocChecker to take up after SmartPtrModelling from [analyzer] Remove unnecessary TODO to [analyzer] Enabling MallocChecker to take up after SmartPtrModelling.
Apr 3 2021, 1:51 AM · Restricted Project

Apr 1 2021

RedDocMD added a comment to D97183: [analyzer] Add NoteTag for smart-ptr get().

Right, sorry for the late reply, @NoQ.
I will get to it once I get these assignments off my head.

Apr 1 2021, 12:03 AM · Restricted Project

Mar 26 2021

RedDocMD added a comment to D97183: [analyzer] Add NoteTag for smart-ptr get().

@NoQ, what do you think?

Mar 26 2021, 12:11 PM · Restricted Project

Mar 25 2021

RedDocMD added inline comments to D97183: [analyzer] Add NoteTag for smart-ptr get().
Mar 25 2021, 6:09 AM · Restricted Project
RedDocMD added inline comments to D97183: [analyzer] Add NoteTag for smart-ptr get().
Mar 25 2021, 5:16 AM · Restricted Project

Mar 22 2021

RedDocMD added a comment to D96976: [analyzer] Fix reinterpret_cast handling for pointer-to-member.

@steakhal?

Mar 22 2021, 11:51 PM · Restricted Project
RedDocMD added a comment to D97183: [analyzer] Add NoteTag for smart-ptr get().

@NoQ, I have taken a different approach this time. I have used a visitor and am storing some more data in the GDM. Together, they distinguish between the following three cases:

  1. If the raw pointer obtained from get() is constrained to null in a path which leads to a Node (and thus State) where a smart-pointer-null-deref bug occurs.
  2. If the raw pointer was null to begin with (because the smart-pointer was null)
  3. If the raw pointer was not null to begin with but the smart-ptr became null after that.

Only in the first case should the note be emitted. I have added some more tests to that effect.
Can you please have a look at this?

Mar 22 2021, 11:49 PM · Restricted Project
RedDocMD updated the diff for D97183: [analyzer] Add NoteTag for smart-ptr get().

Removed extra includes

Mar 22 2021, 11:33 PM · Restricted Project
RedDocMD updated the diff for D97183: [analyzer] Add NoteTag for smart-ptr get().

Repaired git history

Mar 22 2021, 11:29 PM · Restricted Project
RedDocMD updated the diff for D97183: [analyzer] Add NoteTag for smart-ptr get().

Changed approach to use visitor

Mar 22 2021, 11:26 PM · Restricted Project

Mar 21 2021

RedDocMD added a comment to D97183: [analyzer] Add NoteTag for smart-ptr get().

@NoQ, why does the following trigger a null-dereference warning? (https://godbolt.org/z/Kxox8qd16)

void g(std::unique_ptr<A> a) {
  A *aptr = a.get();
  if (!aptr) {}
  a->foo();
}

When a->foo() is called, the constraint !aptr is no longer valid and so InnerPointerVal corresponding to a is no longer constrained to be null.
Am I missing something?

Mar 21 2021, 10:59 PM · Restricted Project
RedDocMD updated the diff for D97183: [analyzer] Add NoteTag for smart-ptr get().

Added some more tests

Mar 21 2021, 9:58 PM · Restricted Project
RedDocMD updated the diff for D97183: [analyzer] Add NoteTag for smart-ptr get().

Re-formatted file

Mar 21 2021, 1:53 AM · Restricted Project

Mar 20 2021

RedDocMD added inline comments to D97183: [analyzer] Add NoteTag for smart-ptr get().
Mar 20 2021, 11:35 PM · Restricted Project
RedDocMD updated the diff for D97183: [analyzer] Add NoteTag for smart-ptr get().

Fixed up the git history

Mar 20 2021, 11:34 PM · Restricted Project

Mar 17 2021

RedDocMD updated the diff for D97183: [analyzer] Add NoteTag for smart-ptr get().

Added some more positive tests

Mar 17 2021, 10:52 PM · Restricted Project