language support: Haskell

[symbioticsec-root]

Hi,

We (Symbiotic Security) have a working Haskell integration in our fork and would like to upstream it.
Before opening a large PR, we'd like to align on approach/scope and how best to coordinate review.

What this adds

• New language: haskell (.hs) recognized by language selection + filename guessing.
• Target parsing + pattern parsing for Haskell via tree-sitter
• Haskell -> AST_generic conversion

Questions

1. tree-sitter packaging: in our fork, tree-sitter generated sources are currently vendored. Would you be ok if we add languages/haskell/tree-sitter/semgrep-haskell as a git submodule (like other languages) to upstream?

2. semgrep_interfaces update: our fork currently points cli/src/semgrep/semgrep_interfaces to a branch in our internal semgrep-interfaces fork (to add Haskell to the language enum). We assume upstream would prefer this as a separate PR to opengrep/semgrep-interfaces first, then update OpenGrep's submodule pointer back to upstream.

3. Are there any acceptance criteria you want us to meet up front (tests, docs, performance/regression expectations, rule/pattern compatibility)?

If it's easier to discuss sequencing/review expectations in a private channel (Slack or similar), we're happy to coordinate that way.
We are open to any suggestions on how best to proceed and look forward to collaborating on this.

[maciejpirog]

Hi @symbioticsec-root,

We definitely welcome such contributions, especially that there are some Haskell nerds among the maintainers.

To answer the questions:

1 and 2. While we find the process with separate submodules per language suboptimal (I don't think we gain anything by keeping them in a separate submodules), it is how it was from the start, and for now let's keep things consistent. I will set up a new repo in the project for the parser, and then you can open three separate PRs (parser + semgrep_interfaces + the main repo), and then we'll worry about merging them in the appropriate order.

3. A comprehensive set of tests will definitely be needed (tests for patterns and taint tracking). Except for that, we add docs in the wiki if we believe there is something the users should know about writing rules or missing features for a given language, but it is not necessary. I don't think there is any risk of a global performance regression when adding a language, unless you need to touch the engine for some reason.

I think there is no reason to move the conversation anywhere else. I do have some ideas where Haskell could be problematic, so I'm eager to see your solution, but let's discuss that after you open the PRs.

I will let you know soon.

[maciejpirog]

@symbioticsec-root
I created a new repo for Haskell within the opengrep project: https://github.com/opengrep/opengrep-haskell
If you could just open three separate PRs we discussed (in the main repo, in semgrep-interfaces, and in opengrep-haskell). Don't worry about submodules pointing to the right commits: you just drop the code, I'll untangle the submodules, and we'll review it ASAP.

[symbioticsec-root]

Thank you for your prompt response. We’ll take care of it as soon as possible.

[symbioticsec-root]

Hi @maciejpirog
Sorry for the delay, I've created the three pull requests:
opengrep/semgrep-interfaces#5
opengrep/opengrep-haskell#1
#660

Let me know if you need anything else from me.
Have a nice day