From 2e4f1e112dfee1d16c138d42f2bc7ee639f9ae05 Mon Sep 17 00:00:00 2001
From: "Stephan T. Lavavej"
Date: Wed, 23 Oct 2019 16:42:47 -0700
Subject: [PATCH] [www] Change URLs to HTTPS.
This changes most URLs in llvm's html files to HTTPS. Most changes were
search-and-replace with manual verification; some changes were manual.
For a few URLs, the websites were performing redirects or had changed
their anchors; I fixed those up manually. This consistently uses the
official https://wg21.link redirector. This also strips trailing
whitespace and fixes a couple of typos.
Fixes D69363.
There are a very small number of dead links for which I don't know any
replacements (they are equally dead as HTTP or HTTPS):
https://llvm.org/cmds/llvm2cpp.html
https://llvm.org/devmtg/2010-11/videos/Grosser_Polly-desktop.mp4
https://llvm.org/devmtg/2010-11/videos/Grosser_Polly-mobile.mp4
https://llvm.org/devmtg/2011-11/videos/Grosser_PollyOptimizations-desktop.mov
https://llvm.org/devmtg/2011-11/videos/Grosser_PollyOptimizations-mobile.mp4
https://llvm.org/perf/db_default/v4/nts/22463
https://polly.llvm.org/documentation/memaccess.html
---
clang/www/OpenProjects.html | 10 +-
clang/www/UniversalDriver.html | 8 +-
clang/www/analyzer/alpha_checks.html | 4 +-
clang/www/analyzer/annotations.html | 42 +-
clang/www/analyzer/available_checks.html | 4 +-
clang/www/analyzer/checker_dev_manual.html | 286 +-
clang/www/analyzer/faq.html | 27 +-
clang/www/analyzer/filing_bugs.html | 9 +-
clang/www/analyzer/implicit_checks.html | 18 +-
clang/www/analyzer/index.html | 15 +-
clang/www/analyzer/installation.html | 9 +-
clang/www/analyzer/open_projects.html | 23 +-
clang/www/analyzer/potential_checkers.html | 80 +-
clang/www/analyzer/release_notes.html | 17 +-
clang/www/analyzer/scan-build.html | 29 +-
clang/www/analyzer/xcode.html | 3 +-
clang/www/comparison.html | 68 +-
clang/www/compatibility.html | 10 +-
clang/www/cxx_compatibility.html | 2 +-
clang/www/cxx_dr_status.html | 4770 ++++++++++----------
clang/www/cxx_status.html | 428 +-
clang/www/demo/DemoInfo.html | 25 +-
clang/www/features.html | 12 +-
clang/www/get_involved.html | 18 +-
clang/www/get_started.html | 8 +-
clang/www/hacking.html | 24 +-
clang/www/index.html | 2 +-
clang/www/related.html | 16 +-
compiler-rt/www/index.html | 44 +-
libclc/www/index.html | 6 +-
libcxx/www/index.html | 2 +-
libcxxabi/www/index.html | 16 +-
libcxxabi/www/spec.html | 68 +-
openmp/www/index.html | 24 +-
polly/www/changelog.html | 2 +-
polly/www/documentation.html | 2 +-
polly/www/get_started.html | 4 +-
polly/www/index.html | 26 +-
polly/www/performance.html | 6 +-
polly/www/phonecall.html | 12 +-
polly/www/projects.html | 4 +-
polly/www/publications.html | 16 +-
polly/www/todo.html | 30 +-
43 files changed, 3110 insertions(+), 3119 deletions(-)
diff --git a/clang/www/OpenProjects.html b/clang/www/OpenProjects.html
index 9d8f4df955ce..e1693cb0e52b 100755
--- a/clang/www/OpenProjects.html
+++ b/clang/www/OpenProjects.html
@@ -44,19 +44,19 @@ doxygen markup, but cannot yet generate documentation from it.
Clang is built as a set of libraries, which means that it is possible to
implement capabilities similar to other source language tools, improving them
in various ways. Three examples are distcc, the distcc, the delta testcase reduction tool, and the
"indent" source reformatting tool.
distcc can be improved to scale better and be more efficient. Delta could be
faster and more efficient at reducing C-family programs if built on the clang
preprocessor. The clang-based indent replacement,
-clang-format,
+clang-format,
could be taught to handle simple structural rules like those in the LLVM coding
+href="https://llvm.org/docs/CodingStandards.html#use-early-exits-and-continue-to-simplify-code">the LLVM coding
standards.
-Use clang libraries to extend Ragel with a JIT: Ragel is a state
+Use clang libraries to extend Ragel with a JIT: Ragel is a state
machine compiler that lets you embed C code into state machines and generate
C code. It would be relatively easy to turn this into a JIT compiler using
LLVM.
diff --git a/clang/www/UniversalDriver.html b/clang/www/UniversalDriver.html
index 2d41a624e14f..bd316e642dc5 100755
--- a/clang/www/UniversalDriver.html
+++ b/clang/www/UniversalDriver.html
@@ -45,7 +45,7 @@ to solve and a proposed implementation (from the user perspective).
development. Stay tuned for more information, and of course, patches
welcome!
-See also PR4127.
+See also PR4127.
Existing Solutions and Related Work
@@ -55,14 +55,14 @@ welcome!
and -m64 solve a small subset of the problem for specific
architectures.
- gcc's multilibs
+ gcc's multilibs
solve the part of the problem that relates to finding appropriate libraries
and include files based on particular feature support (soft float,
etc.).
Apple's "driver driver" supported by gcc and clang solve a subset of the
problem by supporting -arch. Apple also provides a tool chain which
- supports universal
+ supports universal
binaries and object files which may include data for multiple
architectures. See TN2137
for an example of how this is used.
@@ -73,7 +73,7 @@ welcome!
does not match well with tools which are inherently capable of cross
compiling.
- The Debian ArmEabiPort
+ The Debian ArmEabiPort
wiki page for their work to support the ARM EABI provide an interesting
glimpse into how related issues impact the operating system distribution.
diff --git a/clang/www/analyzer/alpha_checks.html b/clang/www/analyzer/alpha_checks.html
index 91ced375710f..3d4075e5aaf9 100644
--- a/clang/www/analyzer/alpha_checks.html
+++ b/clang/www/analyzer/alpha_checks.html
@@ -930,9 +930,9 @@ alpha.unix.SimpleStream
Check for misuses of stream APIs:
fopen
fclose
(demo checker, the subject of the demo
-(Slides
+(Slides
,Video)
-by Anna Zaks and Jordan Rose presented at the
+by Anna Zaks and Jordan Rose presented at the
2012 LLVM Developers' Meeting).
diff --git a/clang/www/analyzer/annotations.html b/clang/www/analyzer/annotations.html
index bfb596094788..bf0076e51427 100644
--- a/clang/www/analyzer/annotations.html
+++ b/clang/www/analyzer/annotations.html
@@ -17,18 +17,18 @@
Source Annotations
The Clang frontend supports several source-level annotations in the form of
-GCC-style
+GCC-style
attributes and pragmas that can help make using the Clang Static Analyzer
more useful. These annotations can both help suppress false positives as well as
enhance the analyzer's ability to find bugs.
This page gives a practical overview of such annotations. For more technical
specifics regarding Clang-specific annotations please see the Clang's list of language
+href="https://clang.llvm.org/docs/LanguageExtensions.html">language
extensions. Details of "standard" GCC attributes (that Clang also
-supports) can be found in the GCC
+supports) can be found in the GCC
manual, with the majority of the relevant attributes being in the section on
-function
+function
attributes.
Note that attributes that are labeled Clang-specific are not
@@ -68,7 +68,7 @@ recognized by GCC. Their use can be conditioned using preprocessor macros
Attribute 'os_consumes_this'
Out Parameters
-
+
@@ -91,7 +91,7 @@ recognized by GCC. Their use can be conditioned using preprocessor macros
The analyzer recognizes the GCC attribute 'nonnull', which indicates that a
function expects that a given function parameter is not a null pointer. Specific
details of the syntax of using the 'nonnull' attribute can be found in GCC's
+href="https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-nonnull-function-attribute">GCC's
documentation.
Both the Clang compiler and GCC will flag warnings for simple cases where a
@@ -108,7 +108,7 @@ parameter.
int bar(int*p, int q, int *r) __attribute__((nonnull(1,3)));
int foo(int *p, int *q) {
- return !p ? bar(q, 2, p)
+ return !p ? bar(q, 2, p)
: bar(p, 2, q);
}
@@ -138,8 +138,8 @@ conventions can cause the analyzer to miss bugs or flag false positives.
One can educate the analyzer (and others who read your code) about methods or
functions that deviate from the Cocoa and Core Foundation conventions using the
attributes described here. However, you should consider using proper naming
-conventions or the objc_method_family
+conventions or the objc_method_family
attribute, if applicable.
Attribute 'ns_returns_retained'
@@ -236,7 +236,7 @@ its availability, as it is not available in earlier versions of the analyzer:The GCC-style (Clang-specific) attribute 'cf_returns_retained' allows one to
annotate an Objective-C method or C function as returning a retained Core
-Foundation object that the caller is responsible for releasing. The
+Foundation object that the caller is responsible for releasing. The
CoreFoundation framework defines a macro CF_RETURNS_RETAINED
that is functionally equivalent to the one shown below.
@@ -323,7 +323,7 @@ href="#attr_cf_returns_retained">cf_returns_retained'. Where a function or
method may appear to obey the Core Foundation or Cocoa conventions and return
a retained Core Foundation object, this attribute can be used to indicate that
the object reference returned should not be considered as an
-"owning" reference being returned to the caller. The
+"owning" reference being returned to the caller. The
CoreFoundation framework defines a macro CF_RETURNS_NOT_RETAINED
that is functionally equivalent to the one shown below.
@@ -353,8 +353,8 @@ its availability, as it is not available in earlier versions of the analyzer:The 'ns_consumed' attribute can be placed on a specific parameter in either
the declaration of a function or an Objective-C method. It indicates to the
static analyzer that a release message is implicitly sent to the
-parameter upon completion of the call to the given function or method. The
-Foundation framework defines a macro NS_RELEASES_ARGUMENT that
+parameter upon completion of the call to the given function or method. The
+Foundation framework defines a macro NS_RELEASES_ARGUMENT that
is functionally equivalent to the NS_CONSUMED macro shown below.
Example
@@ -408,7 +408,7 @@ implicitly passed to a call to CFRelease upon completion of the call
to the given function or method. The CoreFoundation framework defines a macro
CF_RELEASES_ARGUMENT that is functionally equivalent to the
CF_CONSUMED macro shown below.
-
+
Operationally this attribute is nearly identical to 'ns_consumed'.
Example
@@ -438,7 +438,7 @@ void test() {
void test2() {
CFDateRef date = CFDateCreate(0, CFAbsoluteTimeGetCurrent());
consume_CFDate(date); // No leak, including under GC!
-
+
}
@interface Foo : NSObject
@@ -463,7 +463,7 @@ is sent. This matches the semantics of all "init" methods.
follow the standard Cocoa naming conventions.
Example
-
+
#ifndef __has_feature
#define __has_feature(x) 0 // Compatibility with non-clang compilers.
@@ -573,8 +573,8 @@ class MyClass {
OSObject *f;
LIBKERN_RETURNS_NOT_RETAINED OSObject *myFieldGetter();
}
-
-
+
+
// Note that the annotation only has to be applied to the function declaration.
OSObject * MyClass::myFieldGetter() {
return f;
@@ -633,7 +633,7 @@ identified using LIBKERN_RETURNS_RETAINED:
void getterViaOutParam(LIBKERN_RETURNS_NOT_RETAINED OSObject **obj)
-In such cases a retained object is written into an out parameter, which the caller has then to release in order to avoid a leak.
+In such cases a retained object is written into an out parameter, which the caller has then to release in order to avoid a leak.
These two cases are simple - but in practice a functions returning an out-parameter usually also return a return code, and then an out parameter may or may not be written, which conditionally depends on the exit code, e.g.:
@@ -718,7 +718,7 @@ some action that depends on that condition (e.g., dereferencing a pointer).
The analyzer knows about several well-known assertion handlers, but can
automatically infer if a function should be treated as an assertion handler if
it is annotated with the 'noreturn' attribute or the (Clang-specific)
-'analyzer_noreturn' attribute. Note that, currently, clang does not support
+'analyzer_noreturn' attribute. Note that, currently, clang does not support
these attributes on Objective-C methods and C++ methods.
Attribute 'noreturn'
@@ -729,7 +729,7 @@ with a 'noreturn' attribute should never return.
Specific details of the syntax of using the 'noreturn' attribute can be found
in GCC's
+href="https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-noreturn-function-attribute">GCC's
documentation.
Not only does the analyzer exploit this information when pruning false paths,
diff --git a/clang/www/analyzer/available_checks.html b/clang/www/analyzer/available_checks.html
index c610e2bda733..2775743fb849 100644
--- a/clang/www/analyzer/available_checks.html
+++ b/clang/www/analyzer/available_checks.html
@@ -29,8 +29,8 @@ Experimental (Alpha) Checkers.
Default Checkers
diff --git a/clang/www/analyzer/checker_dev_manual.html b/clang/www/analyzer/checker_dev_manual.html
index f5439be35b1e..fd72e4fe3da3 100644
--- a/clang/www/analyzer/checker_dev_manual.html
+++ b/clang/www/analyzer/checker_dev_manual.html
@@ -18,17 +18,17 @@
Checker Developer Manual
- The static analyzer engine performs path-sensitive exploration of the program and
-relies on a set of checkers to implement the logic for detecting and
-constructing specific bug reports. Anyone who is interested in implementing their own
-checker, should check out the Building a Checker in 24 Hours talk
-(slides
+ The static analyzer engine performs path-sensitive exploration of the program and
+relies on a set of checkers to implement the logic for detecting and
+constructing specific bug reports. Anyone who is interested in implementing their own
+checker, should check out the Building a Checker in 24 Hours talk
+(slides
video)
-and refer to this page for additional information on writing a checker. The static analyzer is a
-part of the Clang project, so consult Hacking on Clang
-and LLVM Programmer's Manual
-for developer guidelines and send your questions and proposals to
-cfe-dev mailing list.
+and refer to this page for additional information on writing a checker. The static analyzer is a
+part of the Clang project, so consult Hacking on Clang
+and LLVM Programmer's Manual
+for developer guidelines and send your questions and proposals to
+cfe-dev mailing list.
@@ -58,8 +58,8 @@ for developer guidelines and send your questions and proposals to
Getting Started
- - To check out the source code and build the project, follow steps 1-4 of
- the Clang Getting Started
+
- To check out the source code and build the project, follow steps 1-4 of
+ the Clang Getting Started
page.
- The analyzer source code is located under the Clang source tree:
@@ -69,12 +69,12 @@ for developer guidelines and send your questions and proposals to
See: include/clang/StaticAnalyzer, lib/StaticAnalyzer,
test/Analysis.
- - The analyzer regression tests can be executed from the Clang's build
+
- The analyzer regression tests can be executed from the Clang's build
directory:
$ cd ../../../; cd build/tools/clang; TESTDIRS=Analysis make test
-
+
- Analyze a file with the specified checker:
$ clang -cc1 -analyze -analyzer-checker=core.DivideZero test.c
@@ -85,99 +85,99 @@ for developer guidelines and send your questions and proposals to
$ clang -cc1 -analyzer-checker-help
- - See the analyzer help for different output formats, fine tuning, and
+
- See the analyzer help for different output formats, fine tuning, and
debug options:
$ clang -cc1 -help | grep "analyzer"
-
+
Static Analyzer Overview
- The analyzer core performs symbolic execution of the given program. All the
- input values are represented with symbolic values; further, the engine deduces
- the values of all the expressions in the program based on the input symbols
- and the path. The execution is path sensitive and every possible path through
- the program is explored. The explored execution traces are represented with
- ExplodedGraph object.
- Each node of the graph is
- ExplodedNode,
+ The analyzer core performs symbolic execution of the given program. All the
+ input values are represented with symbolic values; further, the engine deduces
+ the values of all the expressions in the program based on the input symbols
+ and the path. The execution is path sensitive and every possible path through
+ the program is explored. The explored execution traces are represented with
+ ExplodedGraph object.
+ Each node of the graph is
+ ExplodedNode,
which consists of a ProgramPoint and a ProgramState.
- ProgramPoint
- represents the corresponding location in the program (or the CFG).
- ProgramPoint is also used to record additional information on
- when/how the state was added. For example, PostPurgeDeadSymbolsKind
- kind means that the state is the result of purging dead symbols - the
- analyzer's equivalent of garbage collection.
+ ProgramPoint
+ represents the corresponding location in the program (or the CFG).
+ ProgramPoint is also used to record additional information on
+ when/how the state was added. For example, PostPurgeDeadSymbolsKind
+ kind means that the state is the result of purging dead symbols - the
+ analyzer's equivalent of garbage collection.
- ProgramState
+ ProgramState
represents abstract state of the program. It consists of:
- - Environment - a mapping from source code expressions to symbolic
+
- Environment - a mapping from source code expressions to symbolic
values
- Store - a mapping from memory locations to symbolic values
- GenericDataMap - constraints on symbolic values
-
+
Interaction with Checkers
- Checkers are not merely passive receivers of the analyzer core changes - they
+ Checkers are not merely passive receivers of the analyzer core changes - they
actively participate in the ProgramState construction through the
- GenericDataMap which can be used to store the checker-defined part
- of the state. Each time the analyzer engine explores a new statement, it
- notifies each checker registered to listen for that statement, giving it an
- opportunity to either report a bug or modify the state. (As a rule of thumb,
- the checker itself should be stateless.) The checkers are called one after another
- in the predefined order; thus, calling all the checkers adds a chain to the
+ GenericDataMap which can be used to store the checker-defined part
+ of the state. Each time the analyzer engine explores a new statement, it
+ notifies each checker registered to listen for that statement, giving it an
+ opportunity to either report a bug or modify the state. (As a rule of thumb,
+ the checker itself should be stateless.) The checkers are called one after another
+ in the predefined order; thus, calling all the checkers adds a chain to the
ExplodedGraph.
-
+
Representing Values
- During symbolic execution, SVal
- objects are used to represent the semantic evaluation of expressions.
- They can represent things like concrete
- integers, symbolic values, or memory locations (which are memory regions).
- They are a discriminated union of "values", symbolic and otherwise.
- If a value isn't symbolic, usually that means there is no symbolic
- information to track. For example, if the value was an integer, such as
- 42, it would be a ConcreteInt,
- and the checker doesn't usually need to track any state with the concrete
- number. In some cases, SVal is not a symbol, but it really should be
- a symbolic value. This happens when the analyzer cannot reason about something
- (yet). An example is floating point numbers. In such cases, the
- SVal will evaluate to UnknownVal.
- This represents a case that is outside the realm of the analyzer's reasoning
- capabilities. SVals are value objects and their values can be viewed
- using the .dump() method. Often they wrap persistent objects such as
+ During symbolic execution, SVal
+ objects are used to represent the semantic evaluation of expressions.
+ They can represent things like concrete
+ integers, symbolic values, or memory locations (which are memory regions).
+ They are a discriminated union of "values", symbolic and otherwise.
+ If a value isn't symbolic, usually that means there is no symbolic
+ information to track. For example, if the value was an integer, such as
+ 42, it would be a ConcreteInt,
+ and the checker doesn't usually need to track any state with the concrete
+ number. In some cases, SVal is not a symbol, but it really should be
+ a symbolic value. This happens when the analyzer cannot reason about something
+ (yet). An example is floating point numbers. In such cases, the
+ SVal will evaluate to UnknownVal.
+ This represents a case that is outside the realm of the analyzer's reasoning
+ capabilities. SVals are value objects and their values can be viewed
+ using the .dump() method. Often they wrap persistent objects such as
symbols or regions.
- SymExpr (symbol)
- is meant to represent abstract, but named, symbolic value. Symbols represent
- an actual (immutable) value. We might not know what its specific value is, but
- we can associate constraints with that value as we analyze a path. For
- example, we might record that the value of a symbol is greater than
+ SymExpr (symbol)
+ is meant to represent abstract, but named, symbolic value. Symbols represent
+ an actual (immutable) value. We might not know what its specific value is, but
+ we can associate constraints with that value as we analyze a path. For
+ example, we might record that the value of a symbol is greater than
0, etc.
- MemRegion is similar to a symbol.
- It is used to provide a lexicon of how to describe abstract memory. Regions can
- layer on top of other regions, providing a layered approach to representing memory.
- For example, a struct object on the stack might be represented by a VarRegion,
- but a FieldRegion which is a subregion of the VarRegion could
+ MemRegion is similar to a symbol.
+ It is used to provide a lexicon of how to describe abstract memory. Regions can
+ layer on top of other regions, providing a layered approach to representing memory.
+ For example, a struct object on the stack might be represented by a VarRegion,
+ but a FieldRegion which is a subregion of the VarRegion could
be used to represent the memory associated with a specific field of that object.
- So how do we represent symbolic memory regions? That's what
- SymbolicRegion
- is for. It is a MemRegion that has an associated symbol. Since the
+ So how do we represent symbolic memory regions? That's what
+ SymbolicRegion
+ is for. It is a MemRegion that has an associated symbol. Since the
symbol is unique and has a unique name; that symbol names the region.
-
+
Let's see how the analyzer processes the expressions in the following example:
@@ -193,60 +193,60 @@ for developer guidelines and send your questions and proposals to
-Let's look at how x*2 gets evaluated. When x is evaluated,
-we first construct an SVal that represents the lvalue of x, in
-this case it is an SVal that references the MemRegion for x.
-Afterwards, when we do the lvalue-to-rvalue conversion, we get a new SVal,
-which references the value currently bound to x. That value is
-symbolic; it's whatever x was bound to at the start of the function.
-Let's call that symbol $0. Similarly, we evaluate the expression for 2,
-and get an SVal that references the concrete number 2. When
-we evaluate x*2, we take the two SVals of the subexpressions,
-and create a new SVal that represents their multiplication (which in
-this case is a new symbolic expression, which we might call $1). When we
-evaluate the assignment to y, we again compute its lvalue (a MemRegion),
-and then bind the SVal for the RHS (which references the symbolic value $1)
+Let's look at how x*2 gets evaluated. When x is evaluated,
+we first construct an SVal that represents the lvalue of x, in
+this case it is an SVal that references the MemRegion for x.
+Afterwards, when we do the lvalue-to-rvalue conversion, we get a new SVal,
+which references the value currently bound to x. That value is
+symbolic; it's whatever x was bound to at the start of the function.
+Let's call that symbol $0. Similarly, we evaluate the expression for 2,
+and get an SVal that references the concrete number 2. When
+we evaluate x*2, we take the two SVals of the subexpressions,
+and create a new SVal that represents their multiplication (which in
+this case is a new symbolic expression, which we might call $1). When we
+evaluate the assignment to y, we again compute its lvalue (a MemRegion),
+and then bind the SVal for the RHS (which references the symbolic value $1)
to the MemRegion in the symbolic store.
-The second line is similar. When we evaluate x again, we do the same
-dance, and create an SVal that references the symbol $0. Note, two SVals
+The second line is similar. When we evaluate x again, we do the same
+dance, and create an SVal that references the symbol $0. Note, two SVals
might reference the same underlying values.
-To summarize, MemRegions are unique names for blocks of memory. Symbols are
-unique names for abstract symbolic values. Some MemRegions represents abstract
-symbolic chunks of memory, and thus are also based on symbols. SVals are just
-references to values, and can reference either MemRegions, Symbols, or concrete
+To summarize, MemRegions are unique names for blocks of memory. Symbols are
+unique names for abstract symbolic values. Some MemRegions represents abstract
+symbolic chunks of memory, and thus are also based on symbols. SVals are just
+references to values, and can reference either MemRegions, Symbols, or concrete
values (e.g., the number 1).
-
Idea for a Checker
- Here are several questions which you should consider when evaluating your
+ Here are several questions which you should consider when evaluating your
checker idea:
- - Can the check be effectively implemented without path-sensitive
+
- Can the check be effectively implemented without path-sensitive
analysis? See AST Visitors.
-
- - How high the false positive rate is going to be? Looking at the occurrences
- of the issue you want to write a checker for in the existing code bases might
+
+
- How high the false positive rate is going to be? Looking at the occurrences
+ of the issue you want to write a checker for in the existing code bases might
give you some ideas.
-
- - How the current limitations of the analysis will effect the false alarm
- rate? Currently, the analyzer only reasons about one procedure at a time (no
- inter-procedural analysis). Also, it uses a simple range tracking based
+
+
- How the current limitations of the analysis will effect the false alarm
+ rate? Currently, the analyzer only reasons about one procedure at a time (no
+ inter-procedural analysis). Also, it uses a simple range tracking based
solver to model symbolic execution.
-
+
- Consult the Bugzilla database
- to get some ideas for new checkers and consider starting with improving/fixing
+ href="https://bugs.llvm.org/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=REOPENED&version=trunk&component=Static%20Analyzer&product=clang">Bugzilla database
+ to get some ideas for new checkers and consider starting with improving/fixing
bugs in the existing checkers.
@@ -266,7 +266,7 @@ need to be made:
Checker Registration
All checker implementation files are located in
clang/lib/StaticAnalyzer/Checkers folder. The steps below describe
- how the checker SimpleStreamChecker, which checks for misuses of
+ how the checker SimpleStreamChecker, which checks for misuses of
stream APIs, was registered with the analyzer.
Similar steps should be followed for a new checker.
@@ -305,16 +305,16 @@ was successfully added by seeing if it appears in the list of available checkers
Events, Callbacks, and Checker Class Structure
All checkers inherit from the
+href="https://clang.llvm.org/doxygen/classclang_1_1ento_1_1Checker.html">
Checker template class; the template parameter(s) describe the type of
events that the checker is interested in processing. The various types of events
that are available are described in the file
+href="https://clang.llvm.org/doxygen/CheckerDocumentation_8cpp_source.html">
CheckerDocumentation.cpp
For each event type requested, a corresponding callback function must be
defined in the checker class (
+href="https://clang.llvm.org/doxygen/CheckerDocumentation_8cpp_source.html">
CheckerDocumentation.cpp shows the
correct function name and signature for each event type).
@@ -335,13 +335,13 @@ the analyzer cannot be sure whether the file was closed or not.
These events that will be used for each of these actions are, respectively, PreCall,
+href="https://clang.llvm.org/doxygen/classclang_1_1ento_1_1check_1_1PreCall.html">PreCall,
PostCall,
+href="https://clang.llvm.org/doxygen/classclang_1_1ento_1_1check_1_1PostCall.html">PostCall,
DeadSymbols,
+href="https://clang.llvm.org/doxygen/classclang_1_1ento_1_1check_1_1DeadSymbols.html">DeadSymbols,
and PointerEscape.
+href="https://clang.llvm.org/doxygen/classclang_1_1ento_1_1check_1_1PointerEscape.html">PointerEscape.
The high-level structure of the checker's class is thus:
@@ -376,22 +376,22 @@ several macros designed for this purpose. They are:
- REGISTER_TRAIT_WITH_PROGRAMSTATE:
+href="https://clang.llvm.org/doxygen/ProgramStateTrait_8h.html#ae4cddb54383cd702a045d7c61b009147">REGISTER_TRAIT_WITH_PROGRAMSTATE:
Used when the state information is a single value. The methods available for
state types declared with this macro are get, set, and
remove.
- REGISTER_LIST_WITH_PROGRAMSTATE:
+href="https://clang.llvm.org/doxygen/CheckerContext_8h.html#aa27656fa0ce65b0d9ba12eb3c02e8be9">REGISTER_LIST_WITH_PROGRAMSTATE:
Used when the state information is a list of values. The methods available for
state types declared with this macro are add, get,
remove, and contains.
- REGISTER_SET_WITH_PROGRAMSTATE:
+href="https://clang.llvm.org/doxygen/CheckerContext_8h.html#ad90f9387b94b344eaaf499afec05f4d1">REGISTER_SET_WITH_PROGRAMSTATE:
Used when the state information is a set of values. The methods available for
state types declared with this macro are add, get,
remove, and contains.
- REGISTER_MAP_WITH_PROGRAMSTATE:
+href="https://clang.llvm.org/doxygen/CheckerContext_8h.html#a6d1893bb8c18543337b6c363c1319fcf">REGISTER_MAP_WITH_PROGRAMSTATE:
Used when the state information is a map from a key to a value. The methods
available for state types declared with this macro are add,
set, get, remove, and contains.
@@ -438,11 +438,11 @@ new data category; the name of this type is the name of the data category with
"Ty" appended. For REGISTER_TRAIT_WITH_PROGRAMSTATE, this will simply
be passed data type; for the other three macros, this will be a specialized
version of the llvm::ImmutableList,
+href="https://llvm.org/doxygen/classllvm_1_1ImmutableList.html">llvm::ImmutableList,
llvm::ImmutableSet,
+href="https://llvm.org/doxygen/classllvm_1_1ImmutableSet.html">llvm::ImmutableSet,
or llvm::ImmutableMap
+href="https://llvm.org/doxygen/classllvm_1_1ImmutableMap.html">llvm::ImmutableMap
templated class. For the ExampleDataType example above, the type
created would be equivalent to writing the declaration:
@@ -465,9 +465,9 @@ analyzer core by calling the CheckerContext::addTransition function.
When a checker detects a mistake in the analyzed code, it needs a way to
report it to the analyzer core so that it can be displayed. The two classes used
to construct this report are BugType
+href="https://clang.llvm.org/doxygen/classclang_1_1ento_1_1BugType.html">BugType
and
+href="https://clang.llvm.org/doxygen/classclang_1_1ento_1_1BugReport.html">
BugReport.
@@ -496,39 +496,39 @@ analysis, as the program can continue to run after the leak. Dereferencing a
null pointer, on the other hand, should stop analysis, as there is no way for
the program to meaningfully continue after such an error.
- If analysis can continue, then the most recent ExplodedNode
-generated by the checker can be passed to the BugReport constructor
-without additional modification. This ExplodedNode will be the one
+ If analysis can continue, then the most recent ExplodedNode
+generated by the checker can be passed to the BugReport constructor
+without additional modification. This ExplodedNode will be the one
returned by the most recent call to CheckerContext::addTransition.
+href="https://clang.llvm.org/doxygen/classclang_1_1ento_1_1CheckerContext.html#a264f48d97809707049689c37aa35af78">CheckerContext::addTransition.
If no transition has been performed during the current callback, the checker should call CheckerContext::addTransition()
+href="https://clang.llvm.org/doxygen/classclang_1_1ento_1_1CheckerContext.html#a264f48d97809707049689c37aa35af78">CheckerContext::addTransition()
and use the returned node for bug reporting.
If analysis can not continue, then the current state should be transitioned
into a so-called sink node, a node from which no further analysis will be
performed. This is done by calling the
+href="https://clang.llvm.org/doxygen/classclang_1_1ento_1_1CheckerContext.html#adeea33a5a2bed190210c4a2bb807a6f0">
CheckerContext::generateSink function; this function is the same as the
addTransition function, but marks the state as a sink node. Like
addTransition, this returns an ExplodedNode with the updated
state, which can then be passed to the BugReport constructor.
-After a BugReport is created, it should be passed to the analyzer core
-by calling CheckerContext::emitReport.
+After a BugReport is created, it should be passed to the analyzer core
+by calling CheckerContext::emitReport.
AST Visitors
- Some checks might not require path-sensitivity to be effective. Simple AST walk
- might be sufficient. If that is the case, consider implementing a Clang
- compiler warning. On the other hand, a check might not be acceptable as a compiler
- warning; for example, because of a relatively high false positive rate. In this
- situation, AST callbacks checkASTDecl and
- checkASTCodeBody are your best friends.
+ Some checks might not require path-sensitivity to be effective. Simple AST walk
+ might be sufficient. If that is the case, consider implementing a Clang
+ compiler warning. On the other hand, a check might not be acceptable as a compiler
+ warning; for example, because of a relatively high false positive rate. In this
+ situation, AST callbacks checkASTDecl and
+ checkASTCodeBody are your best friends.
Testing
- Every patch should be well tested with Clang regression tests. The checker tests
- live in clang/test/Analysis folder. To run all of the analyzer tests,
+ Every patch should be well tested with Clang regression tests. The checker tests
+ live in clang/test/Analysis folder. To run all of the analyzer tests,
execute the following from the clang build directory:
$ bin/llvm-lit -sv ../llvm/tools/clang/test/Analysis
@@ -796,9 +796,9 @@ Documentation for how the Store works
-
Documentation about inlining
- The "Building a Checker in 24 hours" presentation given at the November 2012 LLVM Developer's
+href="https://llvm.org/devmtg/2012-11">November 2012 LLVM Developer's
meeting. Describes the construction of SimpleStreamChecker. Slides
+href="https://llvm.org/devmtg/2012-11/Zaks-Rose-Checker24Hours.pdf">Slides
and video
are available.
@@ -807,15 +807,15 @@ are available.
Artem Degrachev: Clang Static Analyzer: A Checker Developer's Guide
(reading the previous items first might be a good idea)
- The list of Implicit Checkers
-- Clang doxygen. Contains
+
- Clang doxygen. Contains
up-to-date documentation about the APIs available in Clang. Relevant entries
have been linked throughout this page. Also of use is the
-LLVM doxygen, when dealing with classes
+LLVM doxygen, when dealing with classes
from LLVM.
-- The
+
- The
cfe-dev mailing list. This is the primary mailing list used for
discussion of Clang development (including static code analysis). The
-archive also contains
+archive also contains
a lot of information.
diff --git a/clang/www/analyzer/faq.html b/clang/www/analyzer/faq.html
index 516233b24bf9..72ca27eb8c36 100644
--- a/clang/www/analyzer/faq.html
+++ b/clang/www/analyzer/faq.html
@@ -173,13 +173,13 @@ Note that this cast does not affect code generation.
- In the contrived example above, the analyzer has detected that the body of
-the loop is never entered for the case where length <= 0. In this
-particular example, you may know that the loop will always be entered because
-the input parameter length will be greater than zero in all calls to this
-function. You can teach the analyzer facts about your code as well as document
-it by using assertions. By adding assert(length > 0) in the beginning
-of the function, you tell the analyzer that your code is never expecting a zero
+ In the contrived example above, the analyzer has detected that the body of
+the loop is never entered for the case where length <= 0. In this
+particular example, you may know that the loop will always be entered because
+the input parameter length will be greater than zero in all calls to this
+function. You can teach the analyzer facts about your code as well as document
+it by using assertions. By adding assert(length > 0) in the beginning
+of the function, you tell the analyzer that your code is never expecting a zero
or a negative value, so it won't need to test the correctness of those paths.
@@ -198,15 +198,15 @@ int foo(int length) {
There is currently no solid mechanism for suppressing an analyzer warning,
although this is currently being investigated. When you encounter an analyzer
bug/false positive, check if it's one of the issues discussed above or if the
-analyzer annotations can
-resolve the issue. Second, please report it to
+analyzer annotations can
+resolve the issue. Second, please report it to
help us improve user experience. As the last resort, consider using __clang_analyzer__ macro
described below.
Q: How can I selectively exclude code the analyzer examines?
- When the static analyzer is using clang to parse source files, it implicitly
-defines the preprocessor macro __clang_analyzer__. One can use this
+ When the static analyzer is using clang to parse source files, it implicitly
+defines the preprocessor macro __clang_analyzer__. One can use this
macro to selectively exclude code the analyzer examines. Here is an example:
@@ -215,8 +215,8 @@ macro to selectively exclude code the analyzer examines. Here is an example:
#endif
-This usage is discouraged because it makes the code dead to the analyzer from
-now on. Instead, we prefer that users file bugs against the analyzer when it flags
+This usage is discouraged because it makes the code dead to the analyzer from
+now on. Instead, we prefer that users file bugs against the analyzer when it flags
false positives.
@@ -224,4 +224,3 @@ false positives.
|