C#: Add VS Code model editor queries#14200
Conversation
This is really cool! |
|
@michaelnebel Thank you for the review! I've implemented your feedback, although I'm not very familiar with CodeQL, so I'm not entirely sure about the changes for the unbound declarations. |
There was a problem hiding this comment.
Thank you once again for doing this!
I have added a couple of more comments. Besides the comments in the code, it also worth considering, whether we need a DCA test suite for these queries as they are excluded from all existing test suites (in the selectors). When doing changes to the queries going forward, it is nice to have some tooling to verify that we don't break the results they produce and/or breaks their performance.
For consistency, I will also trigger a DCA run for one of our query suites for check that these queries are indeed excluded by the selector update.
csharp/ql/test/utils/modeleditor/FetchApplicationModeMethods.qlref
Outdated
Show resolved
Hide resolved
csharp/ql/test/utils/modeleditor/FetchFrameworkModeMethods.qlref
Outdated
Show resolved
Hide resolved
| | PublicGenericInterface.cs:7:10:7:14 | stuff | GitHub.CodeQL.PublicGenericInterface<>#stuff(T) | false | supported | PublicGenericInterface.cs | library | | type | unknown | classification | | ||
| | PublicGenericInterface.cs:9:10:9:19 | stuff2<> | GitHub.CodeQL.PublicGenericInterface<>#stuff2<>(T2) | false | supported | PublicGenericInterface.cs | library | | type | unknown | classification | | ||
| | PublicGenericInterface.cs:11:17:11:27 | staticStuff | GitHub.CodeQL.PublicGenericInterface<>#staticStuff(System.String) | false | supported | PublicGenericInterface.cs | library | | type | unknown | classification | | ||
| | PublicInterface.cs:7:10:7:14 | stuff | GitHub.CodeQL.PublicInterface#stuff(System.String) | false | supported | PublicInterface.cs | library | | type | unknown | classification | |
There was a problem hiding this comment.
All the callables are reported to be not supported as there doesn't exist any models for them.
Maybe consider to add some positive testcases for this as well.
It is possible to add a data extension file that only applies to an individual test case (codeql test run looks for .ext.yml files with the same name as the test case). That is, if you add a file called FetchFrameworkModeMethods.ext.yml you can add models for some of your testmethods.
This will implicitly help in testing that we got the predicates for isSupported right (e.g. getAnInput and getAnOutput). The ApplicationMode testcase primarily targets "source" models.
There was a problem hiding this comment.
Thanks for the suggestion! I've added 4 new methods with the 4 different types of models. The summaryModel and neutralModel seem to work, but I can't get the sinkModel or sourceModel to work. Would you be able to take a look and check why those are not working?
There was a problem hiding this comment.
I think the problem is that the implementation requires that for a callable to be identified as a source or sink there needs to be an actual call to it (this works fine for the queries that are just interested in callables NOT the source code). We need to do something else for the analysis that should respect source and sink models for EndPoints in the source code (I will look into this).
Thank you and totally understandable! You are doing great! |
|
DCA using the |
How would I go about doing that? Would I need to create a new |
How would I go about doing that? Would I need to create a new |
| /** Provides classes and predicates related to handling APIs for the VS Code extension. */ | ||
|
|
||
| private import csharp | ||
| private import dotnet |
There was a problem hiding this comment.
No need to import this (and no need to use DotNet::).
| * Otherwise the name of the nested type is prefixed with a `+` and appended to | ||
| * the name of the enclosing type, which might be a nested type as well. | ||
| */ | ||
| private string nestedName(Declaration declaration) { |
There was a problem hiding this comment.
Can be restricted to types instead of declarations in general
| } | ||
|
|
||
| /** Gets a node that is an output from a call to this API. */ | ||
| private DataFlow::Node getAnOutput() { |
There was a problem hiding this comment.
This will include post-update nodes for arguments, e.g. for a call
Foo(x)[post-update] x will be included, which is likely not what you want. Instead I suggest you use getAnOutNode from DataFlowDispatch.qll which will only include normal returns and out/ref returns.
| endpoint.isSupported() and result = true | ||
| or | ||
| not endpoint.isSupported() and | ||
| result = false |
There was a problem hiding this comment.
| endpoint.isSupported() and result = true | |
| or | |
| not endpoint.isSupported() and | |
| result = false | |
| if endpoint.isSupported() then result = true else result = false |
Yes. I have added one here: https://github.com/github/codeql-dca/pull/1663 |
|
DCA Experiment only on this branch: https://github.com/github/codeql-dca-main/issues/16281 |
|
DCA looks good in terms of performance. |
|
@hvitved : Do you have an objections on merging as is? |
|
Other comments: |
csharp/ql/src/utils/modeleditor/ApplicationModeEndpointsQuery.qll
Outdated
Show resolved
Hide resolved
michaelnebel
left a comment
There was a problem hiding this comment.
This looks good to me.
Lets try an run DCA again (I will trigger one more execution).
|
It looks like the model editor queries are now executed via DCA. I think the numbers look reasonable. |

This adds two queries that support the CodeQL Model Editor feature in the CodeQL VS Code extension. These queries will be used to retrieve models that can be modeled using MaD. The query results they produce can also be converted to SARIF, hence the static strings in the query.
The
AutomodelVsCode.qllfile is similar toExternalApi.qll, but they are used for completely different purposes, and changes to theExternalApi.qlldo not necessarily need to propagate toAutomodelVsCode.qll.These queries have been in use for a few weeks now in the VS Code extension (see
csharp.ts). Using this, we have confirmed that these queries return the results we need. Once these queries are merged and released, we will switch to resolving the queries from the query packs. We will do so based on the tags.