Use cases for CodeQL for QL

[Marcono1234]

Are there any plans to support CodeQL scanning CodeQL?

There are a few cases which I have noticed or been made aware of where existing queries are flawed or could be simplified:

• Using exists(...) instead of cast.
  When there is only a single variable declared in the exists formula and there are only two expressions inside the exists forumals, one which compares that variable with a variable from the outer scope and one which calls a predicate, then a cast should be used instead, e.g.:

  exists(StringLiteral s | s = result | s.getRepresentedString().isLowercase())

  Should be:

  result.(StringLiteral).getRepresentedString().isLowercase()

• Using exists(...) instead of any(...).
  When there is only a single variable declared in the exists formula and that variable is only referenced once in the formulas of exists, the any expression can be used instead, e.g.:

  exists(StringLiteral s | s.getRepresentedString() = result)

  Can be written as:

  result = any(StringLiteral s).getRepresentedString()

• Including out-of-bounds index in 0-based set literal, e.g.:

  index = [0 .. getNumberOfParameters()]

  Should be:

  index = [0 .. getNumberOfParameters() - 1]

• Not using set literal, e.g.:

  getName() = "a" or getName() = "b"

  Should be written using a set literal expression:

  getName() = ["a", "b"]

[hmakholm]

This is not a bad idea, and in fact we do have an internal prototype for applying CodeQL to the QL language itself. It is not quite polished enough to let loose on the world yet, and it's uncertain when it will be. Currently we're focusing our efforts on adding support for more mainstream languages in dire need of CodeQL-class security analyses.

I'll leave this discussion open to see what other ideas the community has.

[hmakholm]

An additional use case: running the ReDOS checker over QL code would have caught #5613 before it crashed an analysis in the wild.

[intrigus-lgtm]

The QL for QL code is going to be merged soon it seems 🎉
Have a look at this PR: #7410

[erik-krogh]

You have some nice ideas there, and QL-for-QL in a thing now, so now those ideas could become reality.
Feel free to take my quick prototypes from below and make some PRs, otherwise I might do it later.

Using exists(...) instead of cast.

Yes, good idea! I tried to throw up a prototype, and it detects 490 results that from a quick look seem reasonable.

Using exists(...) instead of any(...).

Also a good idea!
A quick prototype finds 122 results.

Including out-of-bounds index in 0-based set literal, e.g.:

I tried out some prototypes, but I was unable to find anything interesting.
I might just be doing it wrong, so inputs on this one are very welcome.

Not using set literal

We already have that query in QL-for-QL.
But a good idea none the less.

[Marcono1234]

Sorry for this super late response.

QL-for-QL looks really interesting (have not used it yet though) and it is great to see that you use it so extensively to improve the existing queries!

Here is one more QL-for-QL query idea: It looks like some queries use regexpMatch instead of set literals, e.g. regexpMatch("long|float|double"). Do you think it would be worth covering that in UseSetLiteral.ql as well? Though maybe the regexpMatch variant can be more concise in some situations.

You can find examples for this with the following regex search pattern:

regexpMatch\("([a-zA-Z0-9]+\|)+[a-zA-Z0-9]+"\)

[erik-krogh]

Here is one more QL-for-QL query idea: It looks like some queries use regexpMatch instead of set literals, e.g. regexpMatch("long|float|double"). Do you think it would be worth covering that in UseSetLiteral.ql as well? Though maybe the regexpMatch variant can be more concise in some situations.

Nice idea.
I think it fits better in a "use equality instead of regular expressions to match constant strings"-query.
I've made one here: #9182, and you can see the results here: https://github.com/github/codeql/pull/9182/checks?check_run_id=6460227197