Put in a TODO
Bug fixes, some cleanup
Ah I see.
As a side note, without the "redundant" invalidation that is being done, the analyzer crashes on shared_ptr. (Because the State essentially remains the same and that's what causes the crash).
Invalidating via the CallEvent
Sun, Jul 25
Removed a fatal bug
@vsavchenko is this okay?
the following code doesn't emit any warnings
This code doesn't seem to have any unique_ptrs in it? It's not like you're modeling this custom class as well? Can you try the same with the actual unique_ptr?
Fri, Jul 23
It turns out that there is already an option called extra-analyzer-config to pass analyzer configs, like setting ModelSmartPtrDereference to true
Thu, Jul 22
But before we go there we should decide whether we want to actually go for inlining (or otherwise default-evaluating) these destructors. If we do, we should probably not spend too much time on improving invalidation in the checker, because default evaluation would do that properly for us anyway (well, it doesn't really dodge any problems such as the absence of the necessary AST so we'll probably have to solve all these problems anyway, just in a different setting). So it's great that we've fixed evalCall for destructors, this could definitely land as a separate patch (tested via debug.AnalysisOrder), but we really need to think what to do next here. So I recommend gathering some data to see if proper destructor evaluation is actually a real problem.
Wed, Jul 21
Tue, Jul 20
This is a minimal model of destructors in smart-ptr.
Other than the need to probably model the destructor of the pointee, is there anything else to do?
Minimal modelling of destructor
Removed unnecessary white space
Refactored out check
Mon, Jul 19
Would this test do?
Added a simple test
Sun, Jul 18
For some reason this revision did not get automatically closed after commit, manually merging it.
Marked test with FIXME notes
Fixed up tests
Post rebase cleanup
Fri, Jul 16
Thu, Jul 15
Post rebase cleanup
Removed one bug, many more to go
Wed, Jul 14
Cleanup, still doesn't work
Tue, Jul 13
Is the syntax of specifying expected notes and warnings documented somewhere? I could not find the note-specific syntax.
Fixing up tests
Removed stupid mistakes
Mon, Jul 12
Sat, Jul 10
Little refactors, one more test
Fri, Jul 9
Thu, Jul 8
I will be figuring out some tests tomorrow morning.
Wed, Jul 7
Mon, Jul 5
Major bug fix
Sun, Jul 4
Fri, Jul 2
Simplify SVal on state split, other refactors
Performing state split on normal comparision ops
Wed, Jun 30
Refactored out common block
Tue, Jun 29
Fixed bug in enum conversion
Sorry for not updating. Was down with fever.
This patch does *not* work now. operationKindFromOverloadedOperator is broken because the maps don't get populated. I am not entirely sure why this is happening.
Will try to fix tomorrow. @NoQ, @vsavchenko, @xazax.hun, @teemperor do you have a hunch as to why this may be happening?
Jun 26 2021
First try at implementing conversion function from OverloadedOperatorKind to BinaryOperatorKind
Jun 25 2021
Removed dump statement
Refactored code, removed duplications, fixed tests, added some more
Jun 24 2021
We have a failing test here (test at line 473).
Which makes me wonder if the handleComparision function is at all called. This is something I need to check.
Removed re-invention, added tests
Jun 22 2021
Logic for handling special cases, when both are unique_ptr
Jun 20 2021
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.
Jun 19 2021
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.
Jun 18 2021
I am closing this since it has been addressed much better by the patches from @vsavchenko.
Some more refactoring
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.
Little changes, a failing test
Jun 17 2021
Marking and un-marking interestingness
Jun 16 2021
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.
Added more info to the TODO
Jun 15 2021
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?
Refactored common code, removed note emission
The current implementation of how notes are emitted in handleSwap is broken. Consider the following code: