Changes the analyzer to believe that methods annotated with _Nonnull from system frameworks indeed return non null objects.
Local methods with such annotation are still distrusted.
rdar://24291919
Details
Diff Detail
Event Timeline
include/clang/StaticAnalyzer/Checkers/Checkers.td | ||
---|---|---|
219 | I think this should probably go in either 'core' or 'apiModeling' (I have a preference for the second). The "nullability" package is for nullability diagnostics. We want this modeling to still take place even when the nullability diagnostics are turned off. | |
lib/StaticAnalyzer/Checkers/NullabilityChecker.cpp | ||
1191 | I don't think the "NS" namespace is the right indicator here. There are a lot of classes in other namespaces ("CI" for CoreImage, "UI" for UIKit, etc.). | |
1194 | We should do this for C function calls as well. There is a large C function API surface area. We shouldn't do it for function pointers or blocks, since those may be client input. | |
1205 | We should not do this for methods on protocols even if they are in the system header. Returns values from protocol represent client inputs, so we don't want to lose coverage in frameworks on defensive code paths that handle when a client returns nil for a method that is declared nonnull. |
I think this should probably go in either 'core' or 'apiModeling' (I have a preference for the second). The "nullability" package is for nullability diagnostics. We want this modeling to still take place even when the nullability diagnostics are turned off.