maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Analysis/weak-dependencies.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

16 lines
481 B
C
Raw Normal View History

[analyzer] Introduce weak dependencies to express *preferred* checker callback evaluation order Checker dependencies were added D54438 to solve a bug where the checker names were incorrectly registered, for example, InnerPointerChecker would incorrectly emit diagnostics under the name MallocChecker, or vice versa [1]. Since the system over the course of about a year matured, our expectations of what a role of a dependency and a dependent checker should be crystallized a bit more -- D77474 and its summary, as well as a variety of patches in the stack demonstrates how we try to keep dependencies to play a purely modeling role. In fact, D78126 outright forbids diagnostics under a dependency checkers name. These dependencies ensured the registration order and enabling only when all dependencies are satisfied. This was a very "strong" contract however, that doesn't fit the dependency added in D79420. As its summary suggests, this relation is directly in between diagnostics, not modeling -- we'd prefer a more specific warning over a general one. To support this, I added a new dependency kind, weak dependencies. These are not as strict of a contract, they only express a preference in registration order. If a weak dependency isn't satisfied, the checker may still be enabled, but if it is, checker registration, and transitively, checker callback evaluation order is ensured. If you are not familiar with the TableGen changes, a rather short description can be found in the summary of D75360. A lengthier one is in D58065. [1] https://www.youtube.com/watch?v=eqKeqHRAhQM Differential Revision: https://reviews.llvm.org/D80905
2020-05-27 18:29:47 +08:00
// RUN: %clang_analyze_cc1 %s -verify \
[analyzer] Don't allow hidden checkers to emit diagnostics Hidden checkers (those marked with Hidden in Checkers.td) are meant for development purposes only, and are only displayed under -analyzer-checker-help-developer, so users shouldn't see reports from them. I moved StdLibraryFunctionsArg checker to the unix package from apiModeling as it violated this rule. I believe this change doesn't deserve a different revision because it is in alpha, and the name is so bad anyways I don't immediately care where it is, because we'll have to revisit it soon enough. Differential Revision: https://reviews.llvm.org/D81750
2020-05-27 18:27:32 +08:00
// RUN: -analyzer-checker=alpha.unix.StdCLibraryFunctionArgs \
[analyzer] Introduce weak dependencies to express *preferred* checker callback evaluation order Checker dependencies were added D54438 to solve a bug where the checker names were incorrectly registered, for example, InnerPointerChecker would incorrectly emit diagnostics under the name MallocChecker, or vice versa [1]. Since the system over the course of about a year matured, our expectations of what a role of a dependency and a dependent checker should be crystallized a bit more -- D77474 and its summary, as well as a variety of patches in the stack demonstrates how we try to keep dependencies to play a purely modeling role. In fact, D78126 outright forbids diagnostics under a dependency checkers name. These dependencies ensured the registration order and enabling only when all dependencies are satisfied. This was a very "strong" contract however, that doesn't fit the dependency added in D79420. As its summary suggests, this relation is directly in between diagnostics, not modeling -- we'd prefer a more specific warning over a general one. To support this, I added a new dependency kind, weak dependencies. These are not as strict of a contract, they only express a preference in registration order. If a weak dependency isn't satisfied, the checker may still be enabled, but if it is, checker registration, and transitively, checker callback evaluation order is ensured. If you are not familiar with the TableGen changes, a rather short description can be found in the summary of D75360. A lengthier one is in D58065. [1] https://www.youtube.com/watch?v=eqKeqHRAhQM Differential Revision: https://reviews.llvm.org/D80905
2020-05-27 18:29:47 +08:00
// RUN: -analyzer-checker=core
typedef __typeof(sizeof(int)) size_t;
struct FILE;
typedef struct FILE FILE;
size_t fread(void *restrict, size_t, size_t, FILE *restrict) __attribute__((nonnull(1)));
void f(FILE *F) {
int *p = 0;
fread(p, sizeof(int), 5, F); // expected-warning{{Null pointer passed to 1st parameter expecting 'nonnull' [core.NonNullParamChecker]}}
}