Feature request: jump to source from .qlref files

[rdmarsh2]

Is your feature request related to a problem? Please describe.
Navigating from a .qlref file in a test directory to the .ql file it's testing takes more steps than I'd like, especially when the source and test are in different qlpacks.

Describe the solution you'd like
In the Explorer sidebar view, the right-click menu for a .qlref file includes an option to open the .ql file which the .qlref file refers to.

[aeisenberg]

The path in the qlref file is relative to the qlpack? I think this is the case, but just want to be sure there are no edge cases or complexities I'm unaware of.

[rdmarsh2]

It's relative to the qlpack that contains the query (which may be one specified in libraryPathDependencies rather than the qlpack that the test is in)

[adityasharad]

It is always a relative path, which we attempt to resolve first from the enclosing directory (the result must still be within the enclosing qlpack), or against each of the qlpacks on the current library path. See the internal implementation here.

I think there is a case here for codeql resolve tests exposing the resolved .ql file path for each .qlref, so that we're not trying to mimic this calculation in the extension.

[aeisenberg]

So, the way you're describing this, it looks like simply given theqlref file, there is no structured way to determine which qlpack it is coming from and the best way to do this would be to update the cli in order to include this information on calls to codeql resolve tests?

[adityasharad]

That is my preference, unless we find other reasons why the CLI cannot expose that information during resolve tests. My understanding is that the CLI knows the current library path and is already performing this structured path lookup when it runs the tests, so we might as well teach it to give us that information a little earlier.

Less elegant alternative: have the extension call resolve library-path and then manually attempt to resolve the relative path against the returned entries. That feels like we're duplicating code in the CLI and extension.

[aeisenberg]

How would that work? I ran this command:

> codeql resolve library-path --query=ql/java/ql/test/query-tests/security/CWE-611/XXE.qlref
--dbscheme=/Users/andrew.eisenberg/Eclipse/git-repos/github/vscode-codeql-starter/ql/java/ql/src/config/semmlecode.dbscheme
--full-library-path=/Users/andrew.eisenberg/Eclipse/git-repos/github/vscode-codeql-starter/ql/java/ql/test:/Users/andrew.eisenberg/Eclipse/git-repos/github/vscode-codeql-starter/ql/java/ql/src
--no-default-compilation-cache
--compilation-cache=/Users/andrew.eisenberg/Eclipse/git-repos/github/vscode-codeql-starter/ql/java/ql/test/.cache

Presumably, I would need to go through the full-library-path section at a time to look for the ql file in the qlref. I would return the first file that exists.

[adityasharad]

Here's an example:

With a github/codeql checkout on the search path in ql:

codeql resolve library-path --query ql/cpp/ql/test/query-tests/AlertSuppression/AlertSuppression.qlref -vvv --format json

gives me

{
  "libraryPath" : [
    "path/to/ql/cpp/ql/test",
    "path/to/ql/cpp/ql/src"
  ],
  "dbscheme" : "path/to/ql/cpp/ql/src/semmlecode.cpp.dbscheme",
  "compilationCache" : [
    "path/to/ql/cpp/ql/test/.cache"
  ],
  "qlPackName" : "codeql-cpp-tests",
  "relativeName" : "codeql-cpp-tests/query-tests/AlertSuppression/AlertSuppression.qlref"
}

Now I have three candidate directories to look in:

• path/to/ql/cpp/ql/test/query-tests/AlertSuppression (parent of the .qlref file)
• path/to/ql/cpp/ql/test
• path/to/ql/cpp/ql/src (the two entries returned in libraryPath)

The qlref file says AlertSuppression.ql, so I resolve that relative path against each of the 3 candidates above, and finally find the query in path/to/ql/cpp/ql/src/AlertSuppression.ql.

[aeisenberg]

Thanks. That's similar to what I was thinking, except I didn't know that the root of the relative path could also be in the containing directory of the qlref.

[edoardopirovano]

I would also lean towards @adityasharad 's initial suggestion of adding a function to the CLI to resolve the path. This avoids duplicating the logic in the extension which would mean it has to be maintained in two places. If you're happy with this @aeisenberg then I'll put this on my TODO list for when I have access to the CLI code.