package zanuda
Install
dune-project
Dependency
Authors
Maintainers
Sources
sha256=0108d8d6e6e23bfe5e5cdade27ae434db921ed4b6f522ea71800f14a7662230e
sha512=c8d633f4083867dfc73caf3b51b63c8c01771f5c286aa0a8357861044448e0b55df38eb695b997df470267ec921adae6f86c73d251fb3e965ac83ebb2c6b856c
doc/README.html
A linter for OCaml+dune projects
A linter is a tool that discovers bugs and obscurities in the code. The name was invented in 1978 paper of S. C. Johnson: Lint, a C Program Checker.
This is a list of currently supported analyses.
From techinical point of view, most of the lints study Typedtree, so the input for linter should be a fully compiled dune project. There is a support of linters that study untyped tree, but I don't expect them to be widely used. These two abstract trees don't allow to find all possible code quirks. Currently, we delegate job of detecting something like f(1)(2)(3)
to ocamlformat.
This linter is inspired by:
- How possible is a clippy-like linter for OCaml?
- My experience in teaching OCaml at my local university.
But I'm aware that there are other linters like Camelot for OCaml and Clippy Rust.
Usage
Examples of 'zanuda' usage could be found in the 'tests' directory. But in short:
Compile your dune project and run this linter via
dune build @check @runtest -j3 zanuda -dir .
It will report found issues using OCaml's alerts
- You could read the documentation about supported lints via
zanuda -dump
. CI runs regularly uploads information about available lints to GitHub Pages. - You could run linter and dump the results in short JSON form:
zanuda -dir . -ordjsonl /tmp/1.rdjsonl
. They could be processed later, for example as review comment via GitHub API. (This reporting is not implemented yet.)
Developping
To get dependecies you could use standard dune/opam machinery:
opam pin add ./ -n
opam install . --deps-only --with-test --with-doc
Running a single test:
dune b @tests/typed/License
Running all tests:
dune test