Add snippets/templates for QL editors

[aeisenberg]

This feature is about adding snippets for adding larger chunks of code in a single keystroke. First, we should come up with a set of possibilities. Look at the QL4E plugin to see what it's doing.

[aeisenberg]

Here's an initial list:

• class --- creates a generic class
• from --- creates a generic from/where/select statement
• predicate --- creates a generic predicate
• exists, forall, some, count, etc --- and all other quantifiers
• We can also use this to add keywords, like override , extends, and, or, etc. Though I'm not yet sure if we should be flooding the system with smaller snippets.

[aeisenberg]

More of a list:

- file metadata --- auto-fill in `@kind`, `@name`, `@id`, `@tags`, etc
- taint tracking
- dataflow tracking
- qhelp comments on top of predicates and classes

[edoardopirovano]

I've started working on this at edoardopirovano/snippets. For your first list of suggestions, VScode's built in snippets functionality (docs) which allows the user to start typing and then see a list of suggested snippets seems to work well, and I've implemented some simple cases in this way.

However, this only allows fixed patterns to be used (with some simple substitutions such as the file name or date), so more complex cases that require some sort of reasoning would not work using this native feature. For instance, in a template taint tracking class, we would need to know what language our query is being run against so that we can choose an appropriate template (in C++ we'll want to extend TaintTrackingConfiguration while in JavaScript we would want to extend TaintTracking::Configuration). It wouldn't be too hard to establish which case we are in (for example, by looking for import cpp or import javascript in the file), but even so this is beyond what can be done while using the native snippets feature.

I guess if we want to stick to the native snippets feature and need templates for the above the only option is to have all the common cases of the template available and require the user to type (the first few letters of) something like "javascript taint tracking" or "cpp taint tracking" to get the right one to come up. I'm not a big fan of this, though. I think a better alternative would be to only use the snippets feature for some simple things (from/where/select, aggregates, etc.) and have a different pathway for inserting more complex templates. For instance, we could add a right click option of "Insert" with sub-options such as "Taint Tracking" and "Dataflow Tracking."

Would you agree this is the best way to proceed @aeisenberg?

[adityasharad]

The data flow APIs are consistent enough across CodeQL-supported languages that I would expect them to work. The import statements would indeed be different (import <language> and possibly import semmle.<path to language>.dataflow.DataFlow/TaintTracking) but the boilerplate should mostly match. There is a DataFlow/TaintTracking::Configuration class in each language.

This said, I'd be happy to see simpler snippets as a starting point and go from there. More complex snippets also have the disadvantage that we need to keep them up to date and make sure they are always compilable with the latest libraries.

[aeisenberg]

I agree that we should start with the simpler snippets since those are non-controversial and can provide some real benefit to users.

Later, we can think about more complex snippets, there are two options as I see it:

1. use placeholders for all the language-specific details
2. one snippet per language

Neither is ideal and I'd lean towards 1) mostly because we should try to avoid hard-coding language assumptions into the extension.

[aeisenberg]

Another option... Instead of using snippets, we could add new commands like CodeQL: Create Taint Tracking Configuration that will create a new file with a default taint tracking config in the current DB language.

[aeisenberg]

It would be neat if we could somehow make these contextual queries.

[edoardopirovano]

Thanks for the input! I'll open a PR with the simpler snippets for now which should be an easy way to start providing some benefit to users. I also agree that commands to generate classes and such based on the current DB language would also be beneficial though it does need a little consideration whether we want to be coding into the extension things that are specific to the current libraries as this will require maintaining them.