Merge pull request #14131 from omahs/patch-1

Docs: fix minor typos

docs/codeql/ql-language-reference/annotations.rst

@@ -302,7 +302,7 @@ after join ordering. This can be useful to prevent the optimiser from choosing
 a sub-optimal join order.
 
 For instance, in the example below, the ``pragma[inline_late]`` and
-``bindingset[x]`` annotations specifiy that calls to ``p`` should be join ordered
+``bindingset[x]`` annotations specify that calls to ``p`` should be join ordered
 in a context where ``x`` is already bound. This forces the join orderer to
 order ``q(x)`` before ``p(x)``, which is more computationally efficient
 than ordering ``p(x)`` before ``q(x)``.

docs/codeql/ql-language-reference/expressions.rst

@@ -557,7 +557,7 @@ for a given ``f``.
 In this query, oranges are available at two different prices, and the
 default ``sum`` aggregate returns a single line where Alice buys an
 orange at a price of 100, another orange at a price of 1, and an apple
-at a price of 100, totalling 201. On the other hand, in the the
+at a price of 100, totalling 201. On the other hand, in the 
 *monotonic* semantics for ``sum``, Alice always buys one orange and
 one apple, and a line of output is produced for each *way* she can
 complete her shopping list.

docs/prepare-db-upgrade.md

@@ -37,7 +37,7 @@ The `compatibility` field takes one of four values:
 
  * **breaking**: the step is unsafe and will prevent certain queries from working.
 
-The `some_relation.rel` line(s) are the actions required to perform the database upgrade. Do a diff on the the new vs old `.dbscheme` file to get an idea of what they have to achieve. Sometimes you won't need any upgrade commands – this happens when the dbscheme has changed in "cosmetic" ways, for example by adding/removing comments or changing union type relationships, but still retains the same on-disk format for all tables; the purpose of the upgrade script is then to document the fact that it's safe to replace the old dbscheme with the new one.
+The `some_relation.rel` line(s) are the actions required to perform the database upgrade. Do a diff on the new vs old `.dbscheme` file to get an idea of what they have to achieve. Sometimes you won't need any upgrade commands – this happens when the dbscheme has changed in "cosmetic" ways, for example by adding/removing comments or changing union type relationships, but still retains the same on-disk format for all tables; the purpose of the upgrade script is then to document the fact that it's safe to replace the old dbscheme with the new one.
 
 Ideally, your downgrade script will perfectly revert the changes applied by the upgrade script, such that applying the upgrade and then the downgrade will result in the same database you started with.
 

docs/qldoc-style-guide.md

@@ -30,7 +30,7 @@ Valid QL comments are known as QLDoc. This document describes the recommended st
 1. Public declarations must be documented.
 1. Non-public declarations should be documented.
 1. Declarations in query files should be documented.
-1. Library files (`.qll` files) should be have a documentation comment at the top of the file.
+1. Library files (`.qll` files) should have a documentation comment at the top of the file.
 1. Query files, except for tests, must have a QLDoc query documentation comment at the top of the file.
 
 ## QLDoc for predicates