The documentation should have a section on how to contribute rules. It should cover benchmarking them on the files in bench/, link to the grammar, remind about rule categories, and link to sections on writing rules, building from source, and writing tests with lit.

Take a look at how HLint does it: https://github.com/ndmitchell/hlint/blob/85cf1b4892e7d0e0dd4b097f1d259bfb0bcac796/README.md#running-with-continuous-integration

There should be a bug subcommand that collects information for bug reports. This would at least include information like that collected by bugreport, but should also include any configuration files and optimally the command-line that leads to the issue.

cf also: https://github.com/rust-cli/human-panic

cargo publish doesn't like it when you modify files outside of OUT_DIR.

These come from the C pre-processor and would help users who must pre-process their Datalog get accurate/useful filenames and line numbers.

Replace the big README with real documentation.

It would be great if each CLI option had a corresponding entry in the configuration file and a corresponding environment variable, all with the correct precedence. There may be a helpful library out there for this.

e.g.

.type T = S | symbol

should just be

.type T = symbol

and

.type T = S | R | S

should be

.type T = S | R

and

.type T = S | R
.type Q = T | S | P

should be

.type T = S | R
.type Q = T | P

This is a bit easier than lit for covering cases like missing a configuration file, etc.: https://rust-cli.github.io/book/tutorial/testing.html#testing-cli-applications-by-running-them

It's optional, so this style rule would ask users to leave it off.

souffle-lint could probably detect some very limited instances of unused variables, e.g., rules with nullary heads and only one clause:

f() :- g(x).

Leads to false positives in the simpl- rules, and the parser is robust to parse errors so it's not really a big problem. Also, don't warn/error on parse errors by default.

Style rule to prefer synonym && to land, etc.

Add a JSON output format for logs to make it easier to integrate souffle-lint with other tools.

https://stackoverflow.com/questions/59205184/how-can-i-change-the-number-of-threads-rayon-uses

Most linting tools have a global configuration file (e.g., ~/.config/souffle-lint/config.yml) and pick up a local one based on a path (e.g. ./souffle-lint.yml). We should do this!

e.g.,

f(cat("foo", "bar")).

should be

f("foobar").

Support this env var, see https://no-color.org/

souffle-lint won't be able to do much type analysis, but we can detect simple type errors like

"str" + 0

or

cat(4, 2)

Can't have duplicate field names!

config/style.yml shows how to enforce variable naming style with souffle-lint. We should add rules for all the other categories of user-named entities.

https://souffle-lang.github.io/pragmas

These might be left over from a debugging session.

The documentation build (conf.py) should run a Python script that reads config/default.yml and formats it nicely as an ReST page to be included in the documentation, a la souffle-lint info.

Really can't figure out why it's not working, when it works just fine for the normal build.

e.g.,

f() :- true.
f(x) :- g(x), false.

It's unsafe!

https://souffle-lang.github.io/types#type-conversion

e.g.,

range(x, y, 1)

should be written

range(x, y)

e.g.,

.type T = symbol | number

is invalid

See https://rust-cli.github.io/book/in-depth/exit-code.html

tree-sitter parsers are robust to errors, so they still produce a syntax tree even if there's a problem. We should have an option to emit a warning if there are any parse errors.

anyhow allows you to attach context to errors with the .context and .with_context methods. More of the errors in souffle-lint should have context!

e.g., don't name a relation exp or ord.

e.g., instead of

f() :- x = 5; x < 5.

write

f() :- x <= 5.

or instead of

f() :- x <= 5, x != 5.

write

f() :- x < 5.

e.g.,

f() :- 5 = 5.
f(x) :- x != x, g(x).

See https://github.com/langston-barrett/souffle-lint/actions/runs/3316236711/jobs/5477795025, the ideal solution would be to install the requirements to build the docs so that Cargo can do so.

It's easy to write a slow rule. Optimally, souffle-lint would detect when a rule is running slow and warn the user. In any case, the documentation should have a section on finding slow rules.