
Show HN: CodeQL-Like Analyzer for Go - quasilyte
https://github.com/quasilyte/go-ruleguard
======
jerf
"ruleguard parses gorules (e.g. rules.go) during the start to load the rule
set. Loaded rules are then used to check the specified targets (Go files,
packages). The rules.go file itself is never compiled, nor executed."

I understand why it's doing this (in terms of being able to use the ast
parser), but it's a bit weird. I'm "writing in Go", but I (assume I) can't use
loops, conditionals, actually run code, etc. That's a weird affordance [1].

I'd suggest looking at the data structures coming out of the parse of the
file, and considering whether or not you can offer a JSON/YAML
(de)serialization of that instead, and whether or not that might be an
acceptable enough format. We still get "tooling" that can deal with it, but
JSON/YAML files don't contain the promise of being Go code, so the affordances
line up with expectations better. (That's cleanly true of JSON. YAML nominally
has some extensions that make that a bit less clear. Then again, you may find
it helpful to let the extensions do their thing; I haven't checked but go-yaml
says it supports map merging [3], which may give you a nice little bit of
abstraction for the users that costs you zero to implement.)

In the complete other direction, I also would be fine with mynegation's
suggestion of actually running it, and letting it be defined by a data
structure the code returns. Then I do really have full Go power, and the
affordances match capabilities again.

(I think I may actually have a slight preference for the JSON/YAML case; it
just _feels_ more like something that can be integrated into CI better, even
though there's nothing technically stopping you from executing Go code. Still,
it's definitely easy both technically and conceptually to say "I'm running
this executable with this input configuration file across my code", where as
"I'm going to compile this specially for the CI process" is just...
cognitively larger.)

[1]:
[https://en.wikipedia.org/wiki/Affordance#As_perceived_action...](https://en.wikipedia.org/wiki/Affordance#As_perceived_action_possibilities)

[2]: [https://github.com/go-yaml/yaml](https://github.com/go-yaml/yaml)

[3]: [https://yaml.org/type/merge.html](https://yaml.org/type/merge.html)

~~~
quasilyte
You might be interested in
[https://github.com/mvdan/gogrep/issues/32#issuecomment-56866...](https://github.com/mvdan/gogrep/issues/32#issuecomment-568662418)

When gogrep becomes more usable as a library, it would be easier to write such
Go programs easier.

As for the alternative formats, I experimented with JSON, TOML and some custom
format that is even terser. It wasn't an easy choice, but I'm pretty
comfortable with the result. That being said, there could be a several input
formats in the future.

------
quasilyte
Features:

* Custom linting rules without re-compilation.

* Diagnostics are written in a declarative way.

* Quickfix action support.

* Powerful match filtering features, like expression type pattern matching.

Uses gogrep for AST pattern matching.

------
mynegation
I like the idea of using the language (golang) itself to write the rules,
instead of DSL or specialized language like Datalog. But why go for a
restricted ad hoc interpretation instead of just executing this code as a
plugin?

~~~
quasilyte
Mostly because plugins support in Go is not ideal and it still requires
compilation (in plugin mode).

I believe Daniel Martí plans to make gogrep usable as a library, so it will be
possible to write such Go programs in the future.

