In this test case, the body of a property is autosynthesized, and its source locations are invalid. Path diagnostic locations must refer to valid source locations, hence we're hitting an assertion. This patch disables the bugvisitor's note, however we'd need to figure out where to stick it eventually. These new "extra notes" of mine might be useful (we could put them at property declaration), i could add them if everybody likes this idea.
Details
- Reviewers
zaks.anna dcoughlin - Commits
- rGfbe891ee05a5: [analyzer] Nullability: fix notes around synthesized ObjC property accessors.
rC304710: [analyzer] Nullability: fix notes around synthesized ObjC property accessors.
rL304710: [analyzer] Nullability: fix notes around synthesized ObjC property accessors.
Diff Detail
Event Timeline
These new "extra notes" of mine might be useful (we could put them at property declaration), i could add them if everybody likes this idea.
What are these? Is there a PR?
It would be great if we could place a note on a parent that has location. For example, can we walk up the location context?
If you do not fix it in this PR, it's definitely worth a FIXME.
What are these? Is there a PR?
The best explanation we currently have, with examples, is D24278
It would be great if we could place a note on a parent that has location.
That's actually the best approach in my opinion, if achievable.
For example, can we walk up the location context?
That wouldn't work this way because we'd have the completely redundant "calling property accessor" piece before that, and "returning..." after that. Instead, i guess i'd try to actually report a note either before entering the call or after returning from the call, so that call enter notes get pruned for having nothing in between.
That wouldn't work this way because we'd have the completely redundant "calling property accessor" piece before that, and "returning..." after that.
I think we should not print "calling" and "returning" for calling into and returning from autogenerated code, If we do, we should fix that as well. Wouldn't it be simpler to just not emit those nodes if we see that they are calling autogenerated code? (Do we have a valid source location in autogenerated context? If not, we could just not print "calling" and "returning" for calls into a body that does not have proper location info.) If you looked into this already and these are not useful suggestions, please, disregard:)
This sounds logical, yeah, i could do that as well (though right now it doesn't work that way, and i suspect nobody tried).
Automatically pop up from bodyfarm-originated code in PathDiagnosticLocation::getStmt().
Avoid putting "Calling..." and "Returning..." notes on Objective-C auto-synthesized property calls, because they would never call visible code later.
Test the newly added path notes.
Thanks! A couple of minor comments below.
lib/StaticAnalyzer/Core/PathDiagnostic.cpp | ||
---|---|---|
712 | Nit: You could probably factor this into a nicely named helper function. | |
717 | Is ParentLC guaranteed never to be null? I would prefer checking for it inside the while. Even if it is not likely to happen now, the code could evolve to handle more cases.. | |
943 | There was a case where we wanted to produce events for auto synthesized code, could you add a comment on what they were? (Otherwise, it's not clear why we need the isPropertyAccessor check.) |
Fix comments.
lib/StaticAnalyzer/Core/PathDiagnostic.cpp | ||
---|---|---|
717 | We're unlikely to begin analysis at top-frames with auto-synthesized code bodies in the future. Added an assertion. |
Nit: You could probably factor this into a nicely named helper function.