Skip to content

Commit 5d0f7ef

Browse files
authored
Merge pull request github#7743 from jketema/doc-fixes
CodeQL documentation fixes
2 parents afd6f58 + 082c712 commit 5d0f7ef

File tree

2 files changed

+4
-4
lines changed

2 files changed

+4
-4
lines changed

docs/codeql/codeql-language-guides/basic-query-for-cpp-code.rst

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -37,7 +37,7 @@ Running the query
3737
3838
import cpp
3939
40-
from IfStmt ifstmt, Block block
40+
from IfStmt ifstmt, BlockStmt block
4141
where ifstmt.getThen() = block and
4242
block.getNumStmt() = 0
4343
select ifstmt, "This 'if' statement is redundant."
@@ -81,10 +81,10 @@ After the initial ``import`` statement, this simple query comprises three parts
8181
+===============================================================+===================================================================================================================+========================================================================================================================+
8282
| ``import cpp`` | Imports the standard CodeQL libraries for C/C++. | Every query begins with one or more ``import`` statements. |
8383
+---------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------+
84-
| ``from IfStmt ifstmt, Block block`` | Defines the variables for the query. | We use: |
84+
| ``from IfStmt ifstmt, BlockStmt block`` | Defines the variables for the query. | We use: |
8585
| | Declarations are of the form: | |
8686
| | ``<type> <variable name>`` | - an ``IfStmt`` variable for ``if`` statements |
87-
| | | - a ``Block`` variable for the statement block |
87+
| | | - a ``BlockStmt`` variable for the statement block |
8888
+---------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------+
8989
| ``where ifstmt.getThen() = block and block.getNumStmt() = 0`` | Defines a condition on the variables. | ``ifstmt.getThen() = block`` relates the two variables. The block must be the ``then`` branch of the ``if`` statement. |
9090
| | | |

docs/codeql/writing-codeql-queries/debugging-data-flow-queries-using-partial-flow.rst

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -55,7 +55,7 @@ If there are still no results and performance is still useable, then it is best
5555
Partial flow
5656
------------
5757

58-
A naive next step could be to change the sink definition to ``any()``. This would mean that we would get a lot of flow to all the places that are reachable from the sources. While this approach may work in some cases, you might find that it produces so many results that it's very hard to explore the findings. It can can also dramatically affect query performance. More importantly, you might not even see all the partial flow paths. This is because the data-flow library tries very hard to prune impossible paths and, since field stores and reads must be evenly matched along a path, we will never see paths going through a store that fail to reach a corresponding read. This can make it hard to see where flow actually stops.
58+
A naive next step could be to change the sink definition to ``any()``. This would mean that we would get a lot of flow to all the places that are reachable from the sources. While this approach may work in some cases, you might find that it produces so many results that it's very hard to explore the findings. It can also dramatically affect query performance. More importantly, you might not even see all the partial flow paths. This is because the data-flow library tries very hard to prune impossible paths and, since field stores and reads must be evenly matched along a path, we will never see paths going through a store that fail to reach a corresponding read. This can make it hard to see where flow actually stops.
5959

6060
To avoid these problems, a data-flow ``Configuration`` comes with a mechanism for exploring partial flow that tries to deal with these caveats. This is the ``Configuration.hasPartialFlow`` predicate:
6161

0 commit comments

Comments
 (0)